Hi,
https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initr...
Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like being at proof-of-concept state. mkosi going fetch stuff from the internet to generate the initrd is clearly a non-starter (maybe not that much of a problem when doing it in koji where the next fedora repo is only one network hop away).
I don't think mkosi is a hard requirement for unified kernel images though. Once the local configuration issues are solved it should be possible to run "dracut --no-hostonly" in koji + ship results instead of doing it on the installed host, no?
An alternative is to use the systemd credential logic for this (this stuff: https://systemd.io/CREDENTIALS/). It allows encrypting and signing small blobs of info (so called "credentials") with the local TPM. They can then safely be stored on an untrusted medium (such as a ESP/boot partition), and are verified/decrypted on access. The "systemd-stub" EFI stub can automatically pick up such encrypted credentials from the ESP too, similar to the extension initrd images mentioned earlier in this thread.
("man systemd-stub" has details on the efi stub btw).
The credentials logic can also be used to for example pass a root pw for the initrd in a safe way.
Does systemd-cryptenroll use this?
When getting the credentials for the encrypted root filesystem (or something else) from somewhere else, i.e. some attestation server such as https://keylime.dev/, how could that be integrated with systemd-creds best? Simply have the agent write to /run/credentials?
My expectation would be that by default we'd just use the GPT auto discovery stuff and for "pet" systems maybe also encode the root device with a credntial, but for "cattle" systems not bother.
Yep.
Is there some fallback mechanism btw? Most cloud images have just four partitions: bios-boot, efi esp, boot and root. And the root filesystem is simply the largest partition ...
take care, Gerd