On Mi, 20.07.22 21:55, Marek Marczykowski-Górecki (marmarek@xxxxxxxxxxxxxxxxxxxxxx) 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
