Re: [EXTERNAL] Re: F45 Change Proposal: Grub EFI For Confidential Computing (self-contained)
Oron Peled <[email protected]>
| Newsgroups | gmane.linux.redhat.fedora.devel |
|---|---|
| Message-ID | <[email protected]> |
Thanks all for the detailed answers: * Initially, I thought the real blocker would be that it's too much footprint for too small gain. * Now I see a clear list of several blockers across multiple domains. Oh well, it was too good to be true ;-) -- Oron Peled On Tuesday, 30 June 2026 17:00:33 IDT Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jun 30, 2026 at 01:42:19PM +0200, Lennart Poettering wrote: > > On Di, 30.06.26 09:43, Zbigniew Jędrzejewski-Szmek ([email protected]) wrote: > > > > > 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: > > > > There are a bunch more issues: > > > > - can't kexec windows, i.e. multi-boot stuff is borked with this > Indeed, I forgot about this. There's even a "prioritized bug" open for this > (https://bugzilla.redhat.com/show_bug.cgi?id=2049849). > > > - no mechanism for passing over userspace tpm event log > This could be handled with LUO… > > > - unclear regarding authenticating invoked kernels, i.e. one would > > expect that on kexec the kernel would authenticate the next kernel, > > and not userspace, but that's not where we are at. > > Zbyszek > -- Oron Peled Voice: +972-4-8228492 -- _______________________________________________ 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