On Mi, 20.07.22 21:55, Marek Marczykowski-Górecki (marmarek@invisiblethingslab.com) wrote:
I wonder if Qubes OS could use any of this work. It seems that it would be incredibly useful, at least if it supported systems using the Xen hypervisor.
That's probably going to be useful for Qubes OS too, indeed.
It would be even better, if kernel cmdline could be pre-measured too, as many kernel parameters may affect overall system security (like disabling iommu). There is currently one major issue with this: finding root filesystem. If the "initrd cmdline" could be separate from "kernel cmdline", then one could include pre-measured safe kernel cmdline (perhaps even hardcoded into kernel binary), while still being able to instruct initrd where to look for the root fs. Of course, initrd would need to be careful about parsing this piece of information (probably having some allowlist of options allowed in this case), but that's a huge improvement already. There were few other ideas for this problem in this very thread too.
So, in my view of the world, the kernel command line is fixated in the unified kernel image (if you use systemd-stub, this already happens if a .cmdline PE section exists, and SecureBoot is on). If you want to override it, then turn off SecureBoot.
I think finding the root fs is something that should be solved without a dynamic kernel command line. I see three options:
1. Don't specify the root fs at all, let systemd-gpt-auto-generator find it for you. It does that by default: it looks for a properly tagged root partition in the GPT partition table the ESP used to boot was found on.
2. If you use a Verity-enabled root fs, then pin the root fs via its top-level hash on the kernel cmdline, and build that one into the unified kernel image. systemd-gpt-auto-generator helps you with that, if you use roothash= on the kernel cmdline, then this is entirely enough for it to find the partitions, and configure them as dm-verity.
3. Use the new credentials logic in systemd, that allows encrypted/authenticated credentials, bound to the TPM2. "Credentials" are just data blobs that you can pass from external sources into a system and from a system into services. These credentials can be optionally encrypted+authenticated against a symmetric key in the TPM. (for details see: https://systemd.io/CREDENTIALS). One data source for these credentials is *.cred files in the directory you put the kernel image in, if you use systemd-stub. The idea would then be: wrap information where to find the root fs in a credential, encrypt/sign it with the key from the TPM, place the result int the ESP. sd-stub then picks it up, passes it to the booted kernel/initrd. The initrd then reads it, decrypts/authenticates it, and then uses the info to mount the rootfs.
Lennart
-- Lennart Poettering, Berlin