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