Re: F45 Change Proposal: Grub EFI For Confidential Computing (self-contained)

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