Hi,
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