Change: Grub EFI For Confidential Computing #3626
Labels
No labels
document it
fast track
meeting
next release
nonresponsive maintainer
packager revocation
pending announcement
provenpackager
python 2 exception
self contained change
stalled
Status
Accepted
Status
Duplicate
Status
Insufficient data
Status
Invalid
Status
Rejected
system wide change
updates policy exception
vote-in-progress
No milestone
No project
No assignees
7 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
fesco/tickets#3626
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
An independent separate incarnation (package) of the GRUB bootloader
for UEFI only that contains a minimal number of built-in modules, and
can quickly boot a Unified Kernel Image (UKI) using Bootloader
Specification (BLS) files. It will be built separately from the main
GRUB package, and does not replace it for general usage.
Owners, do not implement this work until the FESCo vote has explicitly ended.
The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed. See the FESCo ticket policy and the Changes policy for more information.
REMINDER: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the Discourse discussion linked above. Additional discussion may happen on the Fedora Devel mailing list.
I find this to be a difficult thing to vote on. On the one hand I personally do not see the value of having a
grub2-ccin CVM environments (which was a motivation mentioned in the change proposal).On the other hand I can see the benefit of a stripped down grub2 for those of us who want to be UAPI compliant only with DPS, VFAT, etc that works on hardware and might be able to pave over some of the shenanigans that can happen with hardware EFI implementations. For that though
grub2-ccis not yet in a place where it can be that.This stripped down version is at odds though with what I've seen people expect this to turn into (having filesystem drivers, that sort of stuff).
Anyhow since this is just an introduction of a new package and there are no goals yet to implement this in any actual deliverables I am a weak-ish +1 with the potential idea that the changing of the default bootloader from grub2 to grub2-cc in any deliverables should go through the change proposal process.
Same reasoning applies to me. +1
Yeah, same. +1
I wear multiple hats in this discussion (FESCo member, Fedora CoreOS/Atomic Desktops/bootc maintainer, RHEL CoreOS maintainer).
From the RHEL CoreOS maintainer perspective, I'm +1 for this change as this is the option that has been chosen for downstream support in sealed bootable container images for Confidential Computing setups.
From the bootc and Fedora CoreOS maintainer perspective, I'm +1 for this change as we want to be able to develop, test and make available all those components upstream before they flow down into CentOS Stream and RHEL systems.
From the FESCo perspective, I don't think this change brings a lot of value to Fedora and we should focus on using systemd-boot instead, which is much better suited for this use case. This is what I'm actively working on for the Fedora Atomic Desktops sealed images. So I would be 0.
In the end, I'm +1 as this is an additive change that is useful for some groups of Fedora and does not prevent us from doing something else in the future.
Could you clarify why you don't see the value here? Is it because we could boot UKIs directly like Cloud images do? The answer for this one is that we need an interface to let the user choose which version to boot and rollback on boot.
@siosm wrote in #3626 (comment):
Yep; that's exactly why. Specifically because the proposal mentioned that this is useful in CVM environments. I can see the reasoning for having a bootloader when firmware does not provide good means to select what UKI to boot.
weak +1 here too
So yes, directly booting UKIs works, but it's a generally a bad user experience. If you want to rollback, you need to enter the firmware interface to select the fallback boot entry, or you need to have the system actually booted already to switch the entries / UKIs for the next boot.
Directly booting UKIs also means that we don't have shim in the bootchain and that makes a lot of common use cases difficult (locally signing UKI addons to set custom kargs for example).
@siosm wrote in #3626 (comment):
One can also boot shim to UKI if MOKs and SBATs are required, e.g. how it is done currently for RHEL CVM in Azure/AWS. There's no need to have grub2-cc or systemd-boot in between unless you are indeed paving over bad firmware interfaces; usually not the case in CVM but worthwhile on actual hardware.
Anyhow; we're going quite in depth on the techicalities of implementations itself and since most of us are generally (weakly) in favor of having
grub2-ccavailable we don't really need to do that I think 🙂Lot's of good points here from @supakeen and @siosm.
Weak +1 too.
@supakeen wrote in #3626 (comment):
One last bit before hopefully we don't talk about this anymore: there is no guarantee of a quality firmware interface even in cloud environments. AWS and Azure are better than most, but there's a big wide world that Fedora can be used in... 😉
After a week:
APPROVED (+5, 0, 0)