On Wed, Jun 24, 2026 at 7:29 AM Gerd Hoffmann <[email protected]> wrote: > > On Wed, Jun 24, 2026 at 06:48:23AM -0400, Neal Gompa wrote: > > On Wed, Jun 24, 2026 at 6:44 AM Timothée Ravier via devel > > <[email protected]> wrote: > > > > This contradicts the main goal behind this package which is to > > > include as few modules as possible to reduce the attack surface and > > > thus the need for updates. When using UKIs, we only need support for > > > the FAT filesystem that is used to store them in the ESP. > > > But we don't *have* to store UKIs on the ESP, and we would prefer > > *not* doing that. > > Who is "we" and why do you *prefer* not doing that? >
I already said this upthread, David and I in Fedora Cloud. I'm not going to say again why I don't want to. > There are a few cases where you have little choice, specifically if you > have to work with an existing ESP which is too small to hold kernel > images. > > Pretty much any cloud use case (be it confidential or not) is not > affected by size constrains because you generate disk images and can > decide how big you make the ESP. In my book that leaves no good reason > to store the kernels elsewhere, other than backward compatibility to > current practice. > I wish you were right, but you are not. Cloud environments are affected by buggy UEFI code just like everything else. These days AWS isn't as problematic, but when we first experimented with it, AWS instances booting UEFI couldn't even read FAT32 (it was required to be FAT16) and they used to freak out over the protective MBR data. We have encountered other virtualized environments that have similar problems to real PC environments with ESP size, disk layout, binary names, and so on. > UKIs are standalone EFI binaries which can be booted by the firmware > without any help from any boot loader, via BootNNNN entries, or from EFI > shell, so it IMHO is an advantage to have them stored in a place where > the firmware can access them. > Yes, but it is also advantageous to be able to put them in a standard filesystem too. For the same reasons you say, we can also get away with a tiny ESP and allocate as much space as possible since we don't have to deal with things like fwupd (which don't do anything in cloud environments). And maximizing usable space for workloads is ideal. We probably can't make it *too* small since there have been requests to make Fedora Cloud work with MaaS-style deployments for a while now, and it's something being tepidly explored. Fedora Cloud on metal would still need fwupd for those deployments, installed through cloud-init or whatever MaaS mechanism is used to provision. -- 真実はいつも一つ！/ 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
