←back to thread

Bypassing disk encryption on systems with automatic TPM2 unlock

(oddlama.org)
189 points arjvik | 2 comments | 17 Jan 25 03:00 UTC | HN request time: 0.001s | source
Show context
ARob109 ◴[17 Jan 25 05:24 UTC] No.42734364[source]▶
Seems like this could be easily mitigated with a read only root filesystem using dm verity

Store the root hash of the dm verity formatted rootfs in the PCR. If a malicious partition is presented to initrd, its root hash will not match the trusted one stored in the TPM.

Or if you need a writeable rootfs, use fs verity and store the signature of init into the PCR. The trusted init signature won’t match signature of malicious init.

LUKS for encryption and verity for integrity/verification.

replies(4): >>42734409 #>>42736375 #>>42737186 #>>42737763 #
1. ChocolateGod ◴[17 Jan 25 13:15 UTC] No.42737186[source]▶
> If a malicious partition is presented to initrd

The fact the initramfs is not signed/verified on any desktop Linux distro means secure boot is completely pointless right now on Linux, and is very dissapointing.

I know Fedora has been musing with shipping prebuilt initrds, but it raises problems with things like Nvidia where you need the driver to be in the initramfs to have a proper boot screen. There's also UKIs that have the kernel + initramfs in the same EFI binary (and thus signed) for booting by secure boot, but they can become too big for the small EFI partition computers ship with.

replies(1): >>42738281 #
2. blucaz ◴[17 Jan 25 15:08 UTC] No.42738281[source]▶
> The fact the initramfs is not signed/verified on any desktop Linux distro means secure boot is completely pointless right now on Linux, and is very dissapointing.

It is not. There are other, very real and very important problems with that fact and reasons why it should be fixed, but this is not it. The point of SecureBoot is to protect the firmware from userspace. It works very well for that purpose, as evidenced by the facts that exploits to bypass it have to continuosly be found.