On Tue, Dec 05, 2023 at 03:01:04PM -0600, Chris Adams wrote:

Once upon a time, Aoife Moloney amoloney@redhat.com said:

...

• UKIs need this to find the root filesystem without root=... on the

kernel command line.

How does this work in system with more than one Linux install? Or any more-complicated disk setup (e.g. SW RAID)? Does this also lock users out from ALL kernel command-line options?

Using UKIs is optional, if they don't work for your use case just continue using traditional kernels. Our main focus is virtualization use cases and cloud images, where you usually have a simple disk setup.

Independent from that work is being done (mostly in systemd) to allow configure the command line for UKIs in a secure way. New in systemd v254 are addon images which can extend the command line. See "man systemd-stub" for details.

take care, Gerd

On Tue, Dec 05, 2023 at 04:14:00PM -0500, Neal Gompa wrote:

On Tue, Dec 5, 2023 at 3:47 PM Aoife Moloney amoloney@redhat.com wrote:

...

This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

== Summary == Improve support for unified kernels in Fedora.

== Owner ==

• Name: [[User:kraxel| Gerd Hoffmann]]

• Email: kraxel@redhat.com

• Name: [[User:vittyvk| Vitaly Kuznetsov]]

• Email: vkuznets@redhat.com

== Detailed Description == See [[ Changes/Unified_Kernel_Support_Phase_1 ]] for overview and Phase 1 goals.

==== Phase 2 goals ====

• Add support for booting UKIs directly.

** Boot path is shim.efi -> UKI, without any boot loader (grub, sd-boot) involved. ** The UEFI boot configuration will get an entry for each kernel installed. ** Newly installed kernels are configured to be booted once (via BootNext). ** Successful boot of the system will make the kernel update permanent (update BootOrder).

• Enable UKIs for aarch64.

** Should be just flipping the switch, dependencies such as kernel zboot support are merged.

• Add a UEFI-only cloud image variant which uses UKIs.

** Also suitable for being used in confidential VMs. ** Cover both x86_64 and aarch64.

What is the point of using shim in this path? We're not having UKIs signed by Microsoft, and unless the Linux kernel knows how to call shim for certificates, I don't see how this is supposed to be useful for the Microsoft->Fedora->OS boot chain.

The VM UEFI firmware almost always only has the Microsoft certs installed. Thus the only thing it can boot is shim, which is signed by Microsoft. The boot configuration tells shim to boot the desired UKI, signed by Fedora, instead of its compiled default of booting grub.

The only way you could do away with shim is to install the Fedora certs in UEFI directly, which isn't something most public clouds or other VM mgmt tools support well (if at all).

With regards, Daniel

On Wed, Dec 6, 2023 at 5:15 AM Gerd Hoffmann kraxel@redhat.com wrote:

Hi,

...

What is the point of using shim in this path? We're not having UKIs signed by Microsoft, and unless the Linux kernel knows how to call shim for certificates, I don't see how this is supposed to be useful for the Microsoft->Fedora->OS boot chain.

Booting without shim.efi would work only if you enroll the fedora secure boot CA in your firmware's security database. That is not the default, and not all virtualization environments offer the option to do that.

So, on a typical setup with the microsoft keys enrolled the firmware wouldn't load the UKI, exactly because it is not signed by microsoft. shim.efi is needed for everything signed with the fedora keys, be it grub.efi, fwupd.efi, traditional kernels or UKIs.

Also note that fallback.efi (comes with shim and runs in case there is no UEFI boot configuration) will create only uefi boot entries including shim in the boot path, so there is no easy way to exclude shim.

Ideally we would have shim.efi signed with both microsoft and fedora keys. In that case the firmware -> shim.efi -> fedora-signed.efi boot path would work in both cases (fedora keys / microsoft keys enrolled).

Does that mean that the Linux EFI boot code knows how to call back to shim to get the certificates instead of reading the firmware directly? Because without that, shim is kind of pointless. Shim returns the certificates from firmware plus the embedded distribution one (Fedora's in this case) when it's asked for them.

-- 真実はいつも一つ！/ Always, there's only one truth!

Gerd Hoffmann kraxel@redhat.com writes:

Hi,

...

Does that mean that the Linux EFI boot code knows how to call back to shim to get the certificates instead of reading the firmware directly?

No. The linux efi stub doesn't need that.

shim.efi does:

(a) Set efi variables, where the linux kernel can read the certificates from. This works the same way for both traditional kernels and UKIs.

(b) provide an efi protocol for bootloaders, which can be called by grub and systemd-boot to verify the signature for binaries they load (typically the linux kernel, but could also be fwupd.efi).

Note, the protocol is also used by systemd-stub (the base for UKIs) to verify cmdline addons, see

commit 05c9f9c2517c54b98d55f08f8afa67c79be861e8 Author: Luca Boccassi bluca@debian.org Date: Fri May 12 00:55:58 2023 +0100

stub: allow loading and verifying cmdline addons

this AFAIU means that we also need shim in the boot chain if we want to support these addons.

Hi,

On 12/6/23 11:26, Vitaly Kuznetsov wrote:

Gerd Hoffmann kraxel@redhat.com writes:

...

Hi,

...

Does that mean that the Linux EFI boot code knows how to call back to shim to get the certificates instead of reading the firmware directly?

No. The linux efi stub doesn't need that.

shim.efi does:

(a) Set efi variables, where the linux kernel can read the certificates from. This works the same way for both traditional kernels and UKIs.

(b) provide an efi protocol for bootloaders, which can be called by grub and systemd-boot to verify the signature for binaries they load (typically the linux kernel, but could also be fwupd.efi).

Note, the protocol is also used by systemd-stub (the base for UKIs) to verify cmdline addons, see

commit 05c9f9c2517c54b98d55f08f8afa67c79be861e8 Author: Luca Boccassi bluca@debian.org Date: Fri May 12 00:55:58 2023 +0100

 stub: allow loading and verifying cmdline addons

this AFAIU means that we also need shim in the boot chain if we want to support these addons.

That is true, buts its also false. The LoadImage protocol is more than capable of doing exactly what that patch does (AFAIK), and using strictly the UEFI protocols for validation. Of course if you want to backdoor the process then you need to add shim into it, which is part of what that patch is doing.

Jeremy Linton wrote:

This is IMHO a mistake, the systemd-boot and UKI paths are the perfect time to break with shim and require some form of actual fedora/whatever secure boot key enrollment on the machine. Shim's fundamentally backdooring the UEFI security infrastructure, and frankly some of what is being done is pretty sketchy and its somewhat amazing it hasn't broken by vendors cleaning up their UEFI implementations*. Furthermore, the dependency on MS signing shim is also strongly in the pragmatic but not idea category as well.

How about we just use LogoFAIL to bypass Restricted Boot entirely without bothering with signatures at all?

Kevin Kofler

Hi,

On 12/18/23 06:41, Gerd Hoffmann wrote:

On Fri, Dec 15, 2023 at 02:03:27PM -0600, Jeremy Linton wrote:

...

Hi,

...

==== Phase 2 goals ====

• Add support for booting UKIs directly.

** Boot path is shim.efi -> UKI, without any boot loader (grub, sd-boot) involved.

This is IMHO a mistake, the systemd-boot and UKI paths are the perfect time to break with shim and require some form of actual fedora/whatever secure boot key enrollment on the machine.

This is not going to fly. There are too many cases where you simply can't enroll fedora keys, so booting on machines with the MS 3rd party certificate enrolled IMHO must continue to work.

I agree solving this for every possible machine combination is an intractable problem at the moment. But, the UKI use case, as I understand it, is a handful of hyperscalers and machines. Those organizations either participate in this community or we have engineering contacts at who can assist with cleaning it up.

And this isn't unheard of, poke around in a few machine's key database and you will find other distro's keys.

I agree that depending on MS signing exclusively is a problem. I'd love to see fedora signing as an option. Given that EFI binaries can have multiple signatures we could have shim.efi signed by both microsoft and fedora. Which would allow to enroll the fedora keys instead of the microsoft keys (in case your platform offers that option) and everything works as it did before, except that the machine would only accept fedora-signed EFI binaries.

Problem #1 is we don't have that in fedora today. Which btw is different from rhel/centos, where we actually have a second, distro-signed shim binary. Not as useful as one binary with two signatures, but better than nothing.

I'm talking about removing shim from the boot flow. The UKI would be signed with the fedora key same as would be done with shim in the boot path. The fedora public key is itself enrolled in the UEFI key db alongside the assortment of existing db entries, and the boot path would be UEFI->UKI. Alternatively, better instructions for putting specific machines into UEFI setup mode can be provided, and something like the key enroller being used for fedora/libvirt/qemu today is used to replace the key infrastructure (PK/KEK/etc) on a given machine. The argument against this has always been that it breaks multiboot, but that is not applicable here.

Frankly, none of this should be an issue for any machine that conforms to MS's requirements, as there is already a windows/everyone else boot switch to enable the keys needed to boot linux/shim vs the keys needed to boot modern windows versions.

Problem #2 is we don't have a signed system-boot binary. Switching over to use systemd-boot when this has changed should be easy. The UKIs are already placed in $ESP/EFI/Linux, according to the boot loader spec, where systemd-boot would look for them. So the kernel-install workflow would need only minor changes.

I'm not sure that is strictly needed. Your example boot flow shim->UKI depends on the BDS as the boot selector. If that boot flow works for the end user, there isn't a need the systemd-boot loader itself. It does solve various problems, like boot selection and command line editing, and a few other things, but isn't otherwise necessary. Of course it too, would be signed with the fedora keys rather than the MS ones, and maybe it should be built without the shim + LoadImage/StartImage hacks.

Problem #3 is that apparently everything touching fedora secure boot signing takes ages to make any progress. One ticket I've looked at recently (IIRC the one to enable secure boot signing for aarch64) was roughly five years (!) old. So I'm not going to make my change proposals depend on any progress there. But I'll happily file a Phase #3 proposal once the problems outlined above are solved.

Right, but little of it has been strictly technical. Other distro's have signed their aarch64 shim/boot path. That isn't to say there haven't been plenty of technical things needing attention, but those have been in the, "this should be cleaned up" category rather than "it doesn't work" category.

But, your not really asking for more or less of the fedora infra with or without shim in the path. In both cases the UKI is signed with a fedora key. The difference is where the public key(s) gets enrolled.

...

whole UKI concept works at all. Put another way, there isn't really an answer to a generic boots everywhere UKI at the movement unless one is willing to create GB+ UKIs with every boot critical driver in existence,

Well, CoreOS actually does that. They don't use UKIs specifically, but they ship a generic initrd created on fedora infrastructure instead of generating an host-specific initrd on the installed machine (with only the drivers needed on the host included).

Last time I looked it was ~80 MB in size.

Well on x86, and a fair number of SystemReady SR machines, virtio-blk, hyperv's block driver and nvme are enough to mount the rootfs. So a fairly small subset of disk drivers covers a very large percentage of the market. I would expect the the UKI boot to be similar to coreos, in that the users follow the supported hardware guidelines rather than showing up with random RAID/FC/network/whatever adapters.

Largely my point here is that UKI exist to further harden the secure boot path. Organizations that care about this, should also care about the fact that shim provides little additional functionality in this environment and increases the attack surface by doing sketchy things to bypass the standardized secure boot flow. Everyone involved not only has to assure the firmware is perfect, but all the duplicate shim functionality below it is as well. The stop gap has become a permanent part of the boot flow, which was acceptable if the goal is booting everywhere. Its less acceptable when there is an existing shim->grub->UKI/normal boot flow for those organizations that cannot for whatever reason enroll the fedora keys in the firmware and boot without shim.

...

at which point its probably worth revisiting the entire initramfs boot method.

That is *way* beyond the scope of this change proposal ...

take care, Gerd -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Gerd Hoffmann kraxel@redhat.com writes:

...

...

I'm talking about removing shim from the boot flow.

That is not a goal of this change proposal, and it's not up for debate for phase #2. Maybe an option in a later phase, once we have a signed systemd-boot (see below).

Also, we have one more Fedora-specific problem: we can't create a new SB cert for signing UKIs so we're currently using the same cert as the traditional kernel. This works if you enroll the cert in DB but then these kernels are indistinguishable if you only look at PCR7, this complicates creating PCR policies a lot. The problem why we can't have a new SB certificate is not technical but organizational: currently, private parts of the certs are on physical cards which a few people have an issuing a new one is a real pain. Rumor has it this is going to change and I'd really like to have it included in 'phase #3'.

In phase #2, we can probably add an option to 'uki-direct' to add UKIs without shim to BootXXXX, this certainly won't be the default and will require Fedora cert to be enrolled into DB/MOK but for specific use-cases (e.g. AWS with provisioned varstore) this can be used.