On Tue, Jun 30, 2026 at 04:05:52AM +0300, Oron Peled wrote: > On Thursday, 25 June 2026 10:19:49 IDT Vitaly Zaitsev via devel wrote: > > On 25/06/2026 08:59, Gerd Hoffmann wrote: > > > There are reasons why this is model is not used any more and > > > why UEFI firmware is able to read FAT filesystems. > > > > UEFI firmware can read any file system for which it has drivers. Fedora > > simply needs to sign the efifs package with the Fedora Secure Boot key. > > > > systemd-boot supports efifs by default. Users just need to copy the > > required driver to the EFI/systemd/drivers/ directory. > > Reading this thread shows interesting dilemma between different approaches: > * Restrict everything to FAT and get more limited but simpler boot chain > * Allow kernel+initrd in "real" filesystem, but use some "bridge" (GRUB > file systems, EFI drivers, ...) with maintenance issues. > > I don't see a clear "winner" strategy, so I'll bite and try to add another > kind of "bridge" for file system access. > (you are welcome to hit me hard if I'm proposing some total BS) > > What if the boot sequence would be: EFI -> "bootstrap" UKI on FAT -> load and > "kexec" real kernel from "/boot" (not necessarily FAT) > So the "bootstrap" kernel is used as an intermediate boot loader: > * It should have all needed FS drivers built in (but no quality/maintenance > issues like GRUB) > * I'm not sure it really work (e.g: can the initramfs under /boot be > loaded/executed?) > * Even if it does, I'm not sure about the gain -- would the "bootstrap" > kernel be minimal and constant enough so we can consider it as > "filesystem-access shim" ?
This approach has been discussed extensively in the past. The "no more boot loader" project of the grub team implements something like this. It is a flexible and powerful approach, but it does have certain downsides: - This intermediate kernel would still need to be updated frequently. The kernel upstream has embraced the "embrace all CVEs" approach, so we have constant feed of those, and while in practice the great majority wouldn't matter for the kernel as boot-loader, nobody would be able to do the triage, and with the current approach of requiring quick updates of components with known CVEs, we'd be updating that smaller kernel all the time too. - The intermediate kernel creates a problem for PCR prediction and everything that depends on this: automatic decryption of disks, distribution of encrypted secrets, etc. If we use kexec to enter the final kernel, everything that the intermediate kernel measured into PCRs is part of the state and the policies must deal with the explosion of possible combinations. - The intermediate kernel makes it harder to build policies which only allow access to tpm-bound secrets in early boot. For example, we'd like to use a policy where the secret used to automatically decrypt the root disk is only accessible in the initrd. If the first kernel sets up the root disk, then what to we need the second kernel for? If the second kernel sets up the disk, then we need to give it access to secrets and we can't build those policies. - A simplified kernel is still a complex beast. And the more we lean on minimization, the more that kernel diverges from the "normal" one. So the maintenance and testing burder is bigger. - We rely on kexec. Unfortunately there are many drivers where kexec is not realiable. So in particular if we start some graphics or sound, e.g. to show/play the menu, we risk the final system not working properly. Whether those tradeoffs are worth the trouble is the million dollar question. Zbyszek -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
