inaccurate secure/verified boot entries for Windows, macOS and GNU/Linux

[thestinger]

None of these has a complete implementation of secure/verified boot, particularly Windows and regular Linux distributions. You're confusing supporting verifying part of the OS with a full implementation. Verifying only the kernel without verifying the kernel line or even the core OS is not really useful. The kernel doesn't provide useful functionality to users without userspace. Downgrade protection is also needed for this to work properly. Attestation is not the same thing as secure boot and should not be confused with it.

macOS has the most complete implementation of these 3 by far, but as can be seen by the fact it can simply be largely disabled within the OS without any user-facing warnings shown at boot or anything like that, it is not a real implementation yet.

[eylenburg]

Thank you for elaborating on this, I changed it.

[Jeroen0494]

Hi,

When using a unified kernel image (UKI), you can add the Linux kernel, initramfs and cmdline to a single image, and sign it with secure boot. https://wiki.archlinux.org/title/Unified_kernel_image

Linux also has support for dm-verity to secure the whole stack: https://wiki.archlinux.org/title/Dm-verity

I'm not aware of any distro doing this out of the box though.

[thestinger]

When using a unified kernel image (UKI), you can add the Linux kernel, initramfs and cmdline to a single image, and sign it with secure boot. https://wiki.archlinux.org/title/Unified_kernel_image

That's still not a meaningful implementation of verified/secure boot, particularly with the approach that's commonly advocated where the key is on the same machine. There's a lack of support for hardware implementation of verified/secure boot which actually have a chain of trust from hardware and verify each part of the chain along the way without trusting a huge number of keys, lacking downgrade protection, etc.

Linux also has support for dm-verity to secure the whole stack: https://wiki.archlinux.org/title/Dm-verity

The Linux kernel does, but these Linux distributions certainly do not. You cannot use it with them for the base OS. The documentation on it existing there doesn't mean it is supported / usable.

[thestinger]

I'm not aware of any distro doing this out of the box though.

That's fundamentally not how it works. This isn't something you can simply configure yourself to use with a traditional distribution. It also requires that the OS is designed around to actually use it meaningfully where it avoids trust in persistent state. If you're simply placing full trust in persistent state then it's not a real implementation.

[thestinger]

How do you plan to perform full verification of an immutable root partition frozen at a specific root hash in the UKI with a distribution that's fundamentally not based around block-based updates? Who is going to generate the UKI and what's it going to be signed with? What's going to be included in the immutable root partition? How is it going to completely avoid trusting persistent state?

It's quite problematic for so many traditional distributions to be claiming they support secure boot when in reality all they support is using an insecure implementation of verifying the kernel and then it places full trust in everything after that point. The lockdown approach hardly changes things since the kernel does not really do anything useful by itself. What are the high level security properties gained from using it for only the kernel, particularly an incomplete implementation which is missing links in the chain of trust, trusts a whole bunch of keys for firmware, etc. without even a working revocation system and lacks downgrade protection?