Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate UKI support in Fedora CoreOS #1719

Open
travier opened this issue Apr 24, 2024 · 2 comments
Open

Investigate UKI support in Fedora CoreOS #1719

travier opened this issue Apr 24, 2024 · 2 comments
Labels
jira for syncing to jira kind/enhancement

Comments

@travier
Copy link
Member

travier commented Apr 24, 2024

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:

Required work / dependencies:

Not strictly required but would be really nice to have:

Related but not required:

@travier travier added kind/enhancement jira for syncing to jira labels Apr 24, 2024
@travier
Copy link
Member Author

travier commented Apr 24, 2024

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
Copy link

gdonval commented Jun 30, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
jira for syncing to jira kind/enhancement
Projects
None yet
Development

No branches or pull requests

2 participants