On Wed, 2026-06-24 at 14:01 -0400, Jeremy Cline wrote: > On Wed, Jun 24, 2026, at 9:40 AM, Neal Gompa wrote: > > 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. > > > I feel obligated to chime in here and say that I (also in Fedora Cloud) > very much do want UKIs, I do want them on the ESP and I do _not_ want > the bootloader to have to care about more filesystems.
Amen, the bootloader was a necessary evil back in the day because the BIOS was not up to the task. UEFI *is* up to the task and is actually in a much better position to deal with the HW in some ways. Forcing the use of a bootloader and then forcing the bootloader to have a crapton of code to handle many filesystem is just backwards. Sure you may need the *option* to go that way for some bad behaving older hardware, but that should be the exception going forward not the rule. We have the chance to fundamentally simplify ( == less chances of odd errors ) the boot process and make it more standard, and we absolutely should do so. > > > > > > 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. > > If bugs are found we'll fix them. Bugs exist in all software and yet we > persist. Raising the spectre of old bugs not to change the status quo is not being "Fedora First" ... Best, Simo. -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc -- _______________________________________________ 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
