It scares me. What if the chip dies? How am I gonna be able to get my stuff? I don’t fully understand how it works, but where is the encryption saved? On the chip itself or somewhere else?
Outside of Microsoft and Windows, what’s the application for it? Does Linux or UNIX have much use for TPM? Pardon, my ignorance, but I bet this is a good place to ask!
With the amount of different distros you’ve tried (though mostly derivatives of Arch/Debian), I’m actually surprised to see that you haven’t used any derivative of Fedora. Is there any reason in particular?
I forgot to mention Fedora Silverblue. I’ve used it after Micro os and it was a better experience. Fedora seems to have a better out of box experience and had no issues.
I’m not surprised to hear that you preferred Fedora Silverblue over openSUSE MicroOS. Don’t get me wrong, I think that openSUSE Aeon/Kalpa (current names for openSUSE MicroOS Desktop) have a lot of potential. However, as it stands, Fedora’s Atomic Desktops are just more mature.
Hardly. I self-host a bunch of VMs on a home server. It would be a waste of resources having window managers running them just so I can click around once in a while. Also, it takes way more time to set up a container in Docker Desktop compared to just copying across a command to the terminal from a setup guide.
First step, in case you didn’t do that yet: Create a disk image of the partition - you don’t want to try data recovery on the actual data. Easiest is just using dd to dump the disk to another drive.
Next try running testdisk on the image to see if it can find the backup superblocks - if it does you can feed that to fsck to restore the filesystem.
If you know the blocksize of the filesystem you can also run mke2fs with the -S parameter - this will just write the superblocks. Again, only do that on a disk image, not the actual drive.
You can decide yourself if the data in that disk is more valuable than the price of a new disk to store the backup image. If it’s not that valuable I guess you can one-shot it.
You can do all of that on the device - but you only get one shot. If you mess up that’s it - so no sensible person would try any form of data rescue directly on the device. Storage is cheap, if you don’t have sufficient space on your computer just get another external disk.
I know you wont understand where I’m coming from so I wont bother explaining it. If I need another storage device than I’ll just have to wait until next year to get another storage device.
Edit: I don’t understand why I’m getting downvoted but it proves to me that I made the right choice in not explaining my situation.
I don’t think I can use that mostly because my internet package has a data cap and I don’t want to risk exceeding that.
Also, I know it’s not really the time or place for this type of discussion but I’ve noticed recently (within the last few months) that for some reason the Lemmy community has changed. I don’t know if anyone else feels that way but it sometimes seems like some users are unnecessarily hostile/judgemental towards me. I wont say anything more because once again, this is not the time or the place but Lemmy wasn’t like this when I first started using it over two years ago.
If the disc is corrupted it may be failing, recommending ddrescue over dd is probably a better call not knowing anything else about this situation. Essentially, no reason not to use it.
I swear by ddrescue. It’s a situation I strive to never be but i’ve been there before. I used it once to rescue an employees masters capstone project from their dead work laptop.
After reading about it - true. Disadvantage of doing this stuff for a long time - you miss new developments. Only reason I’m aware of testdisk is that I lost the sources of my own superblock search tool, my old binaries broke with a newer glibc, and before reimplementing it I checked if sombody else had done that in a more usable form in the meantime.
Another tool that has helped me when the others couldn’t was RecuperaBit. It has the same restrictions though, you have to do it on an image of the drive.
The hard drive should be connected by SATA or eSATA when making the image. Connecting over USB is just asking for more trouble when the drive is not working correctly.
That has changed over the last few years - I’d prefer a proper usb3 to sata bridge over a shitty sata controller - and the quality of integrated sata controllers isn’t that great nowadays.
I learned a ton from this, it’s kind of “The Book” I guess. For OP, there’s a pretty massive series of blog posts I fumbled along with too, ianthehenry.com/posts/…/introduction/ though it’s a couple years old.
Having read poetterings blog posts a bit and he explains that the TPM2 based encryption is entirely just for system resources (basically everything under / with exception of /home). For home he still “envisions” (its already possible and not really hard with sd-homed) that the encryption is based on the users passphrase/key/whatever and not unlockable by anyone else than the users passphrase/…
I used Linux Mint for about 1.5 years before transitioning to Arch Linux. For me, the transition was to learn more about Linux and to try something new. Thus far, I’m really liking Arch. There have been a few issues that have popped up here and there, like getting Bluetooth devices to connect properly, but the Arch Wiki and forums often have the solution. You just have to spend time reading the articles or the forum responses.
As for other distros, I’ve tried Zorin, Ubuntu, Kubuntu, Pop OS, and KDE Neon before settling on Linux Mint.
Fedora. Fedora is solid, but coming from arch I felt it was lacking so much in the way of the package repos and doing things like secure boot was more effort than it was worth.
Personally, I don’t see how a TPM module is more useful than full disk encryption with a password you enter on boot.
I struggle to see how it makes automatic login safer given it does nothing to protect against the really common threat of someone physically stealing your laptop or desktop.
I don’t trust any encryption or authentication system that I don’t have access to the keys for. Microsoft has also kinda made me feel it’s more for vendor lock in, like they did with secure boot.
Still, I’m probably being unreasonably pessimistic about it though - be interested to see any practical use cases of it.
In theory, the TPM can be used to verify that the bootloader, kernel and injtamfs haven’t been tampered with, which is very very useful as FDE (in the running machine) is only good if that remains true.
I’ve heard that before, but there are two main problems that stick out to me:
A lot of the marketing for TPM (at least when I was setting up bitlocker on Windows) suggests that it’s used to support decrypting drives without a password on boot. But that doesn’t seem to offer any protection from the devices being stolen. The bootloader may be safe but it’s not actually verifying that I’m the one booting the device.
I can’t think of a situation where someone would be able to actually modify the bootloader without also having full access to the files and secrets. Especially in a single-boot environment where every time the system is running, the device is decrypted.
I’m not saying that it’s all just a scam or anything like that, but it really feels like I’m missing something important and obvious.
The bootloader is stored unencrypted on your disk. Therefore it is trivial to modify, the other person just needs to power down your PC, take the hard drive out, mount it on their own PC and modify stuff. This is the Evil Maid attack the other person talked about.
I can’t see that being a reasonable approach for them to take, tbh. One option with TPM is that your system logs in automatically to the desktop, in which case they can just turn it on and use it normally. The other is that it requires a password at some point during startup, to which they could just use a (hardware) keylogger.
It only at most auto logs you into the display manager or more generally into login. Then you still need to get root access to modify anything from there. Login would still be based on user password/key/whatever.
Pretty easy to set up, can be taken out to not be modified at run time unless you want plus not being stolen with the computer itself.
I see only drawbacks with a TPM for a computer system like that. In embedded credentials, mobile applications, cold credential storage, etc… it works very well, but it doesn’t solve any problem that someone tech savvy doesn’t have a better solution for, in my opinion.
If you are a big enough target for an evil maid attack, you are either good enough to circumvent it better than an embedded TPM, or you are rich enough to hire someone who is.
If the device is stolen, your disk is still encrypted at all time. If you believe your OS’s login system is reasonably secure, then the attacker should have no way to access your data: they cannot access the data from software because it is blocked by login screen, they cannot access the data from hardware because it is protected by FDE.
One of the misconceptions I had before is that I assumed that the disk will be decrypted when you enter the LUKS password. This is not true, the password is loaded into the ram, and only decrypts necessary parts to RAM. All the data on the disk is never decrypted, even when you are working in your OS.
they cannot access the data from software because it is blocked by login screen
The system may still be vulnerable to over the network exploits. So for example, if the system is running sshd, and a couple of months from now a root exploit is found (à la heartbleed), the attacker may get inside.
It’s somewhat of a long shot, but it’s still a much larger attack surface than butting your head against a LUKS encrypted drive that’s at rest.
they cannot access the data from hardware because it is protected by FDE.
RAM is not protected by FDE. There are (obviously non-trivial) ways to dump the RAM of a running system (Cold Boot attacks, and other forensic tools exist). So if the attacker is dedicated enough, there are ways.
One of the misconceptions I had before is that I assumed that the disk will be decrypted when you enter the LUKS password. This is not true, the password is loaded into the ram, and only decrypts necessary parts to RAM. All the data on the disk is never decrypted, even when you are working in your OS.
Hah! That would be impractical :) Imagine having to decrypt your entire 32TB drive array everytime you booted your computer.
While I don’t use TPM myself (I dislike being tied to a specific hardware) the way it protects you is:
Disk is protected through encryption, so you can’t remove and inject anything/hack the password.
If boot is protected/signed/authorized only, a random person can’t load an external OS and modify the disk either.
All this together would say, even if someone acquires your computer, they can’t do anything to it without an account with access, or an exploit that works before a user logs.
In a way, the attack surface can be bigger than if you simply encrypted your disk with a key and password protect that key.
The key is only released into ram, so unless the thief can read content from ram they cannot easily decrypt your disk. And most common thief probably do not have that ability.
That being said, you do need a login password to prevent the thief straight up booting into your OS and copy everything using the file manager…
One of the advantage of using TPM with FDE, is that you can use a much longer random password. If I dont use TPM I am forced to use a password I can remember, which is likely the same password I use somewhere else. This means if someone close to me stole my laptop, they will have reasonable chance of guessing my password.
If you know how to use git, you will know how to use docker (provided you know what you want to do). They are completely different programs, yet you can quickly grasp the other instinctively.
Now, Photoshop and Blender - they are also different programs, but if you know Photoshop, you still need to relearn Blender’s interface completely.
This is why I prefer terminal programs in general. Unless it’s more convenient to use GUi, i.e. Drag&Drop file manager, some git tools etc.
I’ve actually been getting into NixOS recently; interested in replacing an old server I’ve had for like 10 years with something I can just build from a bunch of config files.
Can confirm it is confusing and I have no idea how anything works. :D
In my searches, I’ve come across nixos.org/guides/nix-pills/ , which I’ve gone through a few chapters of - seems good so far.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.