Cause there's no user data stored on EFI, and saying "almost-full-disk-except-for-the-EFI-partition-encryption" is a bit cumbersome and, obviously, pedantic.
this post was submitted on 13 Nov 2025
12 points (77.3% liked)
Linux
10114 readers
1028 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
Sure, but unencrypted means it can be tampered with. The bootloader can be modified to write your password to disk and once you boot, submit that to a server somewhere - or worse.
That's precisely why secure boot and TPMs exist - the TPM can store the keys to decrypt the drives and won't give them unless the signed shim executable can be verified; the shim executable then checks the kernel images, options, and DKMS drivers' signatures as well. If the boot partition has been tampered with, the drive won't decrypt except by manual override.
The big problem is Microsoft controls the main secure boot certificate authority, rather than a standards body. This means that either a bad actor stealing the key or Microsoft itself could use a signed malicious binary used to exploit systems.
Still, it's at least useful against petty theft.
TPM sniffing attacks seem possible, but it looks like the kernel uses parameter and session encryption by default to mitigate that: https://docs.kernel.org/security/tpm/tpm-security.html
There’s also PXE boot, secure boot, carrying around a live image on a flash drive, etc.
But any attacker advanced enough to tamper with your EFI partition in an evil-maid scenario has plenty of other options to log and steal your encryption passphrase, so it’s generally a moot point.
With that logic there's no need to even encrypt your partitions 🤷
Absolutely not — the skill level needed to tamper with a bashrc, pull credentials + keys, or generally hunt for sensitive info on an unencrypted disk is worlds apart from the skill level needed to modify an EFI binary.
security isn't real, just increasing deterrence for attackers.
if you can access something, they can access it, it's just a matter of effort needed to get there.
wait wait. the concern here is the unencrypted partition rather than the password to the encrypted disk being known???
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.
And also because "disk" is already too hard for most people. "Partition" would be way way too complicated a concept for most users.
Yeah, my disk's not even full.
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...).
The partition table isn't encrypted either. What a scam.
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.
Must be because full-ish sounds way too much like foolish, making people think it is a useless thing to do.
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.
: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