Sounds like a misnomer to me.
My guess is because that idea became tied to secure boot respectively chassis intrusion quickly, which makes encrypting every last bit unnecessary. There is true FDE baked into SSDs tho - they can store their key in a TPM.
The “disk” in this terminology is actually referring to the partition, which is the active disk when an OS boots. Different partitions are treated as different disks, it’s not about the physical disk.
Say you have 2 drives: one could contain only unencrypted portions of boot information, and the second drive could only contain encrypted partitions.
Then it would meet your definition of how it should work by terminology 😂
There is full disk encryption on Tumbleweeds using TPM and systems boot. It encrypts the ESP (EFI) partition and you supply password or fido2 key to unlock boot loader and disk
That’s not what the question is asking…
True, other distros don’t have full disk encryption, they have partition encryption.
No, not what I’m saying. Any distro can do what you’re describing, they just don’t. It’s not proprietary technology or anything. I could go and make my LUKS whatever open with a key right now, it’s just problematic.
The OP wasn’t asking about any of this though, you’re just throwing your own unrelated “AKSHUALLY” nonsense into the thread. Question was asked and answered.
See ya.
Apparently its a patched grub2 for opensuse, and systemd boot systems. Makes a binary file that is verified by the TPM , different than just using LUKS encryption.
Just sharing for awareness because people often assume that because one diatro does not do it, means Linux doesn’t do it.
Like when everyone complains about Linux not having hibernation, it does.
To add to the other comments: it’s “full-disk” to distinguish it from “per-file” encryption. And “full-partition” didn’t catch on, probably because functionally an unencrypted boot partition makes little practical difference.
I think FDE is different to full partition. If your home partition is encrypted but not your root partition, that’s not FDE. I would say FDE is when the partition that you mount to / is encrypted.
This is more nitpicking. Yes, there’s a difference between partition and disk. But if we want to get technical, it’s not disk encryption unless you’re using a HDD. SSDs don’t have disks.
At the end of the day, FDE would generally imply that all partitions with user data on them are encrypted. So it would generally include root and home partitions, and generally not include the boot partition, and would likely include partitions like /var and /opt, though not necessarily.
I didn’t mean it as nitpicking. I was just responding to you?
There is FULL disk encryption, I have it on tumbleweed with TPM and systemd boot.
This is long but further down it explains grub2 boot as luks unlocker was good , but with TPM secrets and systemd boot they can (edit for accuracy) encrypt a binary boot file that goes in ESP (EFI) partition. TPM asks for password before unlocking bootloader.
Share your lsblk output. It’s likely that your system still leaves the bootloader unencrypted on the disk, even if the kernels and bootloader config are being encrypted (they aren’t encrypted by default on most installs).
It is theoretically possible to have only one partition that is luks encrypted, but this requires you to store the bootloader in the UEFI, and not all motherboards support this, so distros usually just install it to an unencrypted partition. The UEFI needs to be able to read an unencrypted bootloader from somewhere. That’s why it’s somewhat absurd to claim that the ESP can be encrypted, because it simply can’t.
From your link:
One difference is that the kernel and the initrd will be placed in the unencrypted ESP,
Yeah, I’m using a large font in reader mode and I think I had the word encrypted showing without un onscreen.
You are correct, it makes a custom binary in the fat partition that is verified by TPM for unlocking/proceeding, that binary then contains the other parts to move forward.
Well, something has to be. You can have your EFI partition on a separate drive and then the actual drive will be fully encrypted. It’s just as good as we can get, the algorithm for decrypting the data obviously can’t be encrypted.
I think there are implementations with encryption logic stored in the BIOS or on a separate chip, but don’t quote me on that. And even then, the decryption logic itself will be unencrypted, because, as it happens, computers can’t run encrypted code.
efi partition on a separate disk makes a lot of sense actually, imo the biggest point of fde is that your boot environment doesn’t get fucked with from outside your trusted os, so if you put your efi on a read only CD or something and lock your bios to boot into that, that can’t really be tampered with easily in software
As bad as secure boot is, that’s exactly the use case for it. Frankly, you can both swap the CD and solder a new BIOS flash if you are really interested in boot poisoning, the latter is just a tiny bit harder to do without some sort of trace.
I meant software attacks, if your hardware is compromised it’s pretty much already game over unless you use something esoteric like heads maybe
Why not have the BIOS decrypt the disk then continue the boot process as normal?
Mainly because then the manufacturer decides on how your stuff is encrypted, no likie.
What do you mean?? Our Motherboards come equipped with the latest and greatest Military Grade™ MD5 RealGood™ Encryption Technology.
What do you mean it’s not longer considered secure??? Fake news, we’d never lie to you.
You are just moving things. When you change your EFI partition from being unencrypted and asking for your password to the BIOS asking for your password (or other credentials) you just shift the attack surface.
Somewhere there has to be an unencrypted part to start with.
Lock your unencrypted ESP down with secure boot and your own keys (shitty as it is that is in fact the one conceptional usecase of secure boot, not that stupid marketing bullshit MS is doing with getting vendors to pre-install Microsoft keys) to prevent tampering and you are good to go.
If you do this, be sure to make an image of your EFI partition and/or keys and keep it somewhere safe along with whatever is needed to restore the partition. Because if something tempers with it, your computer will stop booting because sighed hashes no longer match the ones calculated and you’ll be locked out of your own system without some sort of way to restore the partition to a safe state.
@onlinepersona@programming.dev
Yes, preventing the boot process when something tempers with the files is the whole point of secure boot.
And beside the backups you should always have (remember: no backup, no pity for you…) the keys to sign your EFI files with are on the encrypted disk so the running system can get updated. So deactivating secure boot again, unlocking your encrypted disk from some live boot stick and fixing it is always an option (as is having a live system at hand signed by the same keys if you want to…).
:I who cares… do you want it to be called system partition encryption? i mean honestly that sounds better imo but its not something that’s a big deal