Neal Gompa wrote: > But we don't *have* to store UKIs on the ESP, and we would prefer > *not* doing that. And aside from that, those three modules are by far > the most used and well-maintained modules. It's not like I'm asking > for HFS+ support to be enabled on grub-cc.
I don't see any case where storing the UKI outside of the ESP (or an eventual FAT32 XBOOTLDR partition) would make sense with this GRUB build. If it is to share space with the rest of the system like https://fedoraproject.org/wiki/Changes/BtrfsBootForCloud then that would not work for the main purpose of this GRUB build, which is Confidential Computing where the root disk is a LUKS device, optionally on top of RAID. The partition with the UKI would either not be part of the LUKS or RAID and then there are no benefits in splitting it out, or it would be part of the LUKS or RAID setup and then this would mean that GRUB would have to somehow understand RAID or LUKS, and that defeats the purpose of this build which is to remove all of the support for complex filesystems and disks layout from GRUB to cut on security issues and config complexity. I want to note here that this is not theoretical and this is how we are doing LUKS/RAID today using Ignition on Fedora CoreOS and how we implemented it for sealed images. The change in https://fedoraproject.org/wiki/Changes/BtrfsBootForCloud only benefits systems with very simple and un-encrypted disk layouts, which is fine when you rely on encryption at another level or can rely on the cloud provider, but not OK in the Confidential Computing case. This would also mean that the GRUB config would have to be tweaked to support that dynamically (how do you figure out which case you are in?), going against the purpose of this minimal build with a minimal config. But I don't really understand why you would want that in this build as you can already do that with the current GRUB build and I don't expect it to do away any time soon. -- _______________________________________________ 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
