On Mi, 08.12.21 18:10, Colin Walters (walters(a)verbum.org) wrote:
Right. I am in favor of having tight integration with the TPM of
course, but it can't be used exclusively.
In particular, I think about half the posters in this thread are
thinking of the desktop case, but the problem can easily happen on
virtualized servers too - that's why we ship the bits we do in
Fedora CoreOS. And we need to consider public and private cloud
(e.g. OpenStack/vSphere) instances which were provisioned without
UEFI, as well as ppc64le and s390x. And still today, the default
for `virt-install` on x86_64 is BIOS.
So I'll just re-surface my idea of having the bootloader either pass
information about its "locked" state to the kernel and to systemd,
or have some sort of more declarative easily parsable config file
for this that systemd could read (i.e. not `grub.cfg`). The former
seems better. Either way there's just one "source of truth" and
admins who *do* want to lock the system against casual keyboard
interactive changes don't need to do it in two places.
In recent sd-stub (i.e. the EFI stub shipped with systemd that you can
glue in front of an ELF kernel to make it an UEFI PE binary with
various nice benefits) added support for loading some select files off
the ESP, wrap them in an on-the-fly generated cpio archive and pass
them on to the invoked Linux kernel as additional initrd. This is
extremely easy to do (because cpio is so easy, it's a bunch of ASCII
characters in front of each file), and is how I would recommend
passing additional possibly even dynamic data from boot loader to the
initrd environment. sd-stub does this for two purposes: to provide
encrypted/authenticated "credentials" (which are passwords, iscsi
passphrases, SSL certificates, whatever you need, optionally bound to
TPM2), and to provide systemd extensions (which are verity
enabled/signed disk images that can be overlayed over OS fs trees, and
which we intend to use to implement trusted, immutable, vendor
Providing additional resources from boot loaders to initrd
environments this way has the major benefit that it just appears in
the fs, i.e. accessible via fs API, is very simple to do, doesn't
require explicit new infra anywhere in the boot chain in between.
sd-stub/sd-boot implement this as mentioned, with the upcoming systemd
250. Legacy boot loaders such as grub could support that too.
Lennart Poettering, Berlin