On Mo, 04.07.22 15:59, Gerd Hoffmann (kraxel(a)redhat.com) wrote:
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).
Well, we didn't find any better tools, i.e. with all the verity stuff
and signing in place. mkosi is just a wrapper around dnf, it's not
really that smart... If it is fine building any kind of RPM-based
image on fedora infra this shouldn't be any different...
we tried to make rh image builder people inetreested in that, but they
weren't interested in that at all.
I don't think mkosi is a hard requirement for unified kernel
No, it's not. mkosi is just a python script gluing all the dnf,
gpt, fdisk, verity, signing stuff together. You can reimplement that.
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?
We want to build initrds from RPM, to make the reasonably reproducible
and follow proper deps. It's a major facet of the project. magic build
scripts trying to magically determine deps from ELF and config and
whatnot is kind what we want to get away from.
> The credentials logic can also be used to for example pass a
> for the initrd in a safe way.
Does systemd-cryptenroll use this?
Use what precisely? the root pw? no, why would it?
or the credentials api? i mean, there's no direct hookup, but we don't
really need it: from the service side credentials are just files in
the file system, and we do support reading keys from that.
When getting the credentials for the encrypted root filesystem (or
something else) from somewhere else, i.e. some attestation server such
, how could that be integrated with systemd-creds
best? Simply have the agent write to /run/credentials?
I don't know keylime. But note that service credentials can be read from a
variety of sources: most prominently regular files on disk you specify
via an fs path. Now one tweak here is that if you actually specify an
AF_UNIX socket inode in the fs as fs path, then we'll connect to it,
and read the credential data from it. This is a flexible way to plug
anything you like into the service credential logic: all keylime has
to do is bind a socket somewhere, with tight perms, and then whenever
a connection comes in just write the credential data into the
connection and close it right after.
> My expectation would be that by default we'd just use the
> discovery stuff and for "pet" systems maybe also encode the root
> device with a credntial, but for "cattle" systems not bother.
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 ...
Actually, the implementation of the gpt auto logic (at least on some
contexts) is somewhat tolerant: if the partitions are not properly
tagged (i.e. use generic type uuids) but there's only a single one
that would be a candidate, then it will be used as root fs. We refuse
working that way though once you have two entirely generic partitions and we
thus have no clue which it could be...
But why not just fix the cloud images to just use descriptive type
uuids? that has no drawbacks, just benefits.
Lennart Poettering, Berlin