On Mi, 20.07.22 21:55, Marek Marczykowski-Górecki (marmarek(a)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