tlaurion
commented
9 months ago @DemiMarie
As of now Heads unpacks initramfs only once, when setting a default boot option, to parse OS provided initramfs crypttab file (which by the way can be in various locations, which are currently though as being all covered) with sole purpose of not guessing what initramfs is actually doing (is it using LUKS uuid? device path? Heads attempt to abstract wrong doing: there is no standard for that. Its not Heads business to change all wrongdoing in the world) to extract what the OS initramfs wants, and only replaces "none" field linked to presence of keyfile, and replaces it with path of where Heads will put secret.key (/secret.key). That's it.
On default boot configured to unseal a TPM DUK, Heads takes the previously defined and detached signed crypttab override file dumped under /boot and generates the PATH:/crypttab file expected by OS's initramfs with the previously trusted override to point to /secret.key and puts secret.key in secret.cpio. That's it!
To do so, it creates a newc cpio and appends it to verified detached signed /boot/initramfs copied in ram, and constructs a kexec call pointing to that newly appended initramfs which is expected to be uncompressed as of today (compressing initramfs is known to be costly for no gain and is largely undone across other OSes).
So as of today, yes Heads uncompresses initramfs (if interested look at initrd/bin/unpack_initramfs.sh) in the purpose of finding where OS decides to put crypttab as explained previously without standard). But at each boot, it just generates secret.cpio with the two files aforementioned and appends the original verified initramfs (against detached signed digest signature with user keys since QubeOS doesn't sign its boot components as of today) and kexecs that initramfs replacement from tmpfs replaced by initramfs. That's it. Then OS initramfs lives its short lived role and is replaced by OS and layoff of which Heads is responsible for is long gone.
Related discussions happened at
- https://github.com/QubesOS/qubes-issues/issues/8763#issuecomment-1858909201
- https://github.com/linuxboot/heads/issues/1499#issuecomment-1858939270
Describe the solution you'd like Instead of Heads injecting the secret into the initramfs, Heads should leave the secret in the TPM for use by the kexec’d OS. The OS is then responsible for using the secret to unlock the drive and for deleting the secret when no longer needed.
As of now this suggestion is also highly impractical. And nobodies is actually doing it. Others, like linuxboot, does a similar thing Heads does. Otherwise, other projects like Ultrablue does it post-pre-boot environement, in systemd initramfs context. This is too late and it is quite unknown why that should be trusted anyway (The sole advanced purpose of Heads is to type DUK passphrase in a measured, verified, and trustworthy environment to dodge the risk of typing a secret in untrusted initramfs. Agreed that your solution would be elegant, but nobody else does that. If prior work is done under systemd to be able to do something similar, then I guess we could either adapt Heads measuring policy and then pass that policy to OS (then we still have to pass something, right?) where as of now, we abstract this, and we pass something that initramfs is suppoed to deal properly now. As said in other issues, the intent here is to deal with what is already in the field today. So here, you are talking about improving things under systemd, which is great. But that issue should be opened here after that impementation is done under systemd, not before.
Note that https://github.com/QubesOS/qubes-issues/issues/8763 and associated QSB https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-098-2023.txt resolved the issue. For now.
Is your feature request related to a problem? Please describe. Unpacking & repacking the initramfs is quite fragile and is not a very elegant solution. More importantly, it is incompatible with Unified Kernel Images (UKIs) that combine the hypervisor, kernel, and initramfs into a single signed binary.
Describe the solution you'd like Instead of Heads injecting the secret into the initramfs, Heads should leave the secret in the TPM for use by the kexec’d OS. The OS is then responsible for using the secret to unlock the drive and for deleting the secret when no longer needed.
Describe alternatives you've considered None.
Additional context This might prevent #1545. It also allows the OS to use other types of encrypted storage, such as encrypted ZFS or bcachefs volumes.