On Mi, 08.12.21 18:10, Colin Walters (walters@xxxxxxxxxx) 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 initrds). 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 -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
