Comment by ARob109

Comment by ARob109 a day ago

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.

ChocolateGod 19 hours ago

> 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.

Reply View 1 reply

blucaz 17 hours ago

> 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.

Reply View | 0 replies

oneplane 18 hours ago

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.

Reply View 0 replies

yx827ha a day ago

That's how ChromeOS does it. https://m.youtube.com/watch?v=iO6cb90WiQ4

Reply View 2 replies

ARob109 a day ago

Android too in a way via Android Verified Boot. I think ChromeOS uses AVB as well.
Android Verified Boot extends the System on chip Hardware based secure boot to the kernel and rootfs. Root of trust is fused into the SoC, and second stage bootloaders are signed. Second stage boot loader eg uboot,UEFI/edk2 contains a public key that is used to verify a signed AVB partition. This signed partition contains signed rootfs dm verity metadata and signed hash of the kernel(+initrd). AVB validates kernel hash with expected hash and loads kernel if good. It provides the trusted rootfs verity hash to kernel via cmdline. Then when kernel reads rootfs, the dmverity system will calculate hash and check if matches the expected one. If not, the system reboots and the AVB metadata is flagged to indicate tampering/failure of the rootfs.
edit to add: If the SoC supports hardware based full disk encryption, the filesystem can be encrypted as well, with the key being stored in Androids secure key store. Android though has moved away from FDE in favor of file based encryption.

Reply View | 1 reply
- bigfatkitten a day ago
  
  The ingredients are there as Chrome OS and Android have shown, but robust hardware-bound disk encryption has just never been a priority for the general purpose distros.
  
  Reply View | 0 replies

highwaylights 21 hours ago

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.

Reply View 0 replies