On Tue, Jun 30, 2026 at 5:44 AM Zbigniew Jędrzejewski-Szmek <[email protected]> wrote: > > 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. >
Yes, this is miserable enough as it is... > - 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. > My personal experience is that any wide-ranging attempt of using the PCR stuff is doomed to failure. Watching Aeon try to use it in the real world and now deciding to rip it out because it's too broken reinforced my view that we are probably never going to use it anytime soon. So the PCR tradeoff pretty much doesn't matter. > - 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. > This is ultimately the biggest problem. Kexec is so brittle that it's effectively not reliable for the wide range of systems we support. > Whether those tradeoffs are worth the trouble is the million dollar question. > I don't think it ever will be. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ 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
