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@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, report it: https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue
