Investigate UKI support in Fedora CoreOS

[travier]

Describe the enhancement

Investigate adding UKI support for Fedora CoreOS for selected cloud / hardware platforms.

UKI are Unified Kernel Images including the kernel, initrd and kernel command line in a single EFI binary that is optionally Secure Boot signed.

System details

Only platforms where it makes sense.

Additional information

See:

• https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
• https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_2
• https://discussion.fedoraproject.org/t/f40-change-proposal-unified-kernel-support-phase-2-system-wide/98298
• Cloud-Base-UEFI-UKI image in Fedora: https://pagure.io/fedora-kiwi-descriptions/blob/rawhide/f/teams/cloud/cloud.xml#_21
• Support UKI ostreedev/ostree#2753

Related but not required:

• systemd-boot support ostreedev/ostree#1719
• Support alternate cmdline entries in UKIs systemd/systemd#24539

[travier]

Some notes from the meeting around what UKI support in FCOS could look like:

There is general push to get away from the split kernel / initramfs & kernel command line and move all thre into a single EFI binary that can be Secure Boot signed: a Unified Kernel Image. This is mostly interesting for security as it makes it significantly easier to implement a measured boot chain and then confidential computing (in the cloud or on capable hardware)

This however clashes with some assumptions that we have today: the kernel command line being easily editable, the initramfs being easily re-generated, only the kernel being Secure Boot signed, etc.

Probably at the cost of some disk space, we can extract the kernel initramfs & command line from a UKI to the system for backward compatibility. We can "unpack" a UKI into a current setup so users that want to modify kargs can drop the UKI and use the current behavior (they won't get the benefits obviously).

See: https://discourse.ubuntu.com/t/how-to-inspect-kernel-efi-uki-universal-kernel-image-binary/38266

The biggest question is around signing, as we produce our own initramfs, so we would have to figure out a way to get them signed by Fedora.

Note that it's not the classic RPM / GPG signature here, it's the Secure Boot one, and I don't know how this works in Fedora. It's only used for the kernel package right now AFAIK.

Users can also enroll their own keys in some platforms, so they could sign their own UKIs and use that. This is particularly useful to be able to change kernel arguments or make derived images for example

The biggest item is thus: the ostree command line argument. The idea is to rely on a signature to select the ostree commit to boot instead of a hash. We include the public key in the initramfs, and then sign the ostree hash with the private key and on boot you go through all ostree commits available and find the one matching the public key in the initramfs.

This however means that we can not share UKIs between boots anymore (like ostree does right now) but it's probably not that much of an issue (excepted that we have size issues in /boot right now).

Other options are to use a single key and include the hash of the deployment in the UKI name instead.

systemd issue around kernel arguments in UKIs: systemd/systemd#24539

It's probably easier to start with a new image first and investigate the integration after

[gdonval]

Taking baby steps that would lead us to somewhere we want to be...

UKIs don't have to replace previous system

Part 0 of this would probably be supporting a mechanism to generate UKIs from individual components.

• /boot can remain exactly as it is for backward compatibility and ostree support.
• /efi would expose the ESP where dracut (or kernel-install) would create, (custom-sign) and place the UKI according to the bootloader spec so that they are automatically picked up.

If the system boots on BIOS or if there is no ESP, there will be no change at all, by design: the "old" entries will continue to work, irrespective to all this (even on UEFI)!

We merely need to boot on Secure Boot now

Currently, admins, or anyone with physical access, can trivially compromise a fcos system: they can replace grub, inject their own initramfs, and modify the kernel command. Therefore the only constraint we have right now is seamless boot on secure-boot-enabled machine, not pretending it provides strong security benefits yet.

Path to strong Secure Boot

When UKIs are there, people who wish to custom-sign images can at least easily do it. Individuals and companies can even use one machine to do exactly this and then seed other machine's ESPs with it. That's short-term gain with minimal effort.

As for Fedora-signed UKIs, that's what the documentation at the top covers. The gist is that all we need is an initramfs (or a set of them) that can setup enough storage to either overlay another initramfs or boot on the system... but that's not the point of this comment.