On 23.05.2023 21:54, Felix Rubio wrote:
Hi everybody,
I am trying to understand something, and after looking around I have not
found any explicit answer. Maybe somebody in this list can shed some
light on the matter? I have a laptop in which I am setting up the boot
process through systemd-boot, and this works. Now, I'd like to give a
try to enable Secure Boot so that the whole boot sequence is protected
against tampering. As I am still learning about the technology, I prefer
to land on the use of shim/MOK. For what I have read, the sequence
should be:
1. Install a version of shim signed with MS keys.
2. On that same folder copy systemd-bootx64.efi, renamed to grubx64.efi
(as shim seems to work only with Grub as 2nd stage loader).
3. Sign the kernel with the key for which the certificate has been
enrolled in MOK.
4. Reboot, enroll the keys and... voila.
So far, so good... until we hit the initramfs wall: the efi's and kernel
signatures are verified, but not that of the initramfs. I have seen that
grub2 does not do it (it relies in GPG signatures, in which seems to be
a workaround), and I have not found any place stating that systemd-boot
GPG is independent alternative method of verifying files and most
certainly not a workaround (it was implemented in grub2 long before
Secure Boot support).
does it. I have seen however, some steering towards the use of UKI...
but this comes with its own problems about out-of-tree kernel modules
and so.
So, the question is: why the kernel image gets verified but not the
initramfs? Is this mandated by some standard, or is an engineering
decision?
Kernel image has verifiable origin (it is signed by the same entity that
provides your distribution). It is static and does not change on end
user system which makes it possible to sign by maintainers of
distribution by a secret key that is hopefully kept secret.
initrd is volatile, it is usually generated on the same system where it
should be verified which means the key to sign it must be kept on the
same system as well. Which makes it more probable that secret key will
be leaked if system is compromised. And leaked secret key allows
installing an arbitrary malware as part of initrd.
Measured boot does not have this problem. If you encrypt your root and
only allow decrypting if initrd (and kernel and any other data used
during boot) has known content then initrd will be implicitly verified
and if it is changed system simply fails to boot. This does not require
any key management or storing any persistent secret on end system.
Downside is that it requires TPM (or some other tamper resistant way to
store hashes) so not universally applicable.
Thank you very much!
