Hi,
> > > 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.
Well, that is the main focus for now. At the end of the day I think
using UKIs is good for all hardware. There are a number of roadblocks
to be solved before they will actually work in more complex setups
though. For the simple cases (no multiboot, ...) and standard storage
(ahci/nvme) the virt UKI does also boot on physical hardware, I have a
thinkpad running with it.
But even when limiting things to the hyperscalers it doesn't work
everywhere. On AWS you can bring your own uefi variable store, with
whatever you want in 'db' etc. On Azure you can't.
> 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).
> 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.
If the 'enroll fedora public key in db' part would be *that* simple shim
would not exist in the first place.
> > 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.
It'll be useful for multiple reasons, especially if you want make shim
optional in the boot chain:
(1) systemd-boot already supports secure boot key enrollment in case
the machine is in setup mode.
(2) It will remove the dependency on shim's fallback.efi (to create
BDS entries for the UKIs on first boot).
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
