alt Hacker NewsSeems 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
That's similar to how Apple does it. The base system is signed (and has a tree of signatures so you don't need to strictly re-calculate the entire RO volume your base OS sits on), and the signature is recorded in the boot configuration.
Granted, you could disable that, but they have thought of that too, you can only disable it from a recovery OS that is signed the same way. But disabling that doesn't disable it for the recovery OS, so you can't evil maid the recovery OS later to make it appear as if it is still enabled.
That's how ChromeOS does it. https://m.youtube.com/watch?v=iO6cb90WiQ4
I’m not sure if this is the exact process for openSUSE Aeon, but it’s very close philosophically so I image the rest is a question of hardening this over time.
> 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.