I agree that the UKI should be booted directly. This would probably work better than my own proposed solution, given that EFI is being used, and that UKIs are already an established booting method. An off-list conversation basically resulted in me coming to the conclusion that something similar to direct-boot UKIs would be the best solution.
The UKI is basically the inevitable result of turning over most of the loading process to EFI, which lends itself to great security by default, since the entire binary can be verified by secure boot; which will include both the kernel, and initramfs. The kernel will of course continue to boot with all of the necessary drivers, which will in turn avoid any potential problems and complications in regards to filesystems. Sent with Proton Mail secure email. On Thursday, June 25th, 2026 at 11:18, Simon de Vlieger <[email protected]> wrote: > On Thu, Jun 11, 2026, at 8:49 PM, Aoife Moloney via devel-announce wrote: > > == Detailed Description == > > > > There is a need for a smaller, lighter version of the GRUB bootloader > > on UEFI to support booting sealed bootable container images, such as > > for Confidential Computing. > > > > Since confidential VMs rely on remote attestation, TPM PCR values need > > to be stable and predictable over long periods of time. Updating the > > bootloader results in changes to PCRs, and should therefore be avoided > > if possible. > Show quoted text > > For current RHEL 10 CVM images (for Azure and AWS) we boot the UKI directly > instead of having a bootloader in between. > > Could we have something in the 'Feedback' section about why there's a need to > have grub2-cc in between. A few reasons have been discussed in this thread > but > they're in disparate places :) > > The proposal seems to target mostly virtual machines: > > > contains only the modules that are absolutely necessary for VMs, and > > natively supports UKI loading > > So it doesn't *feel* like the bootloader would be there to pave over bad > implementations that can't get updated. > > Simon > -- -- _______________________________________________ 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
