Short summary: As part of UEFI Secure Boot support, Fedora must include newly signed versions of the bootloader binaries (shim and grub) on Fedora 34 installation media and images so that UEFI Secure Boot enabled systems can boot the installation media and images themselves.
Current bootloaders: shim 15, grub2 2.04
New bootloaders: shim 15.3, grub2 2.06
Detail: the current shim was signed in 2018 and its signing key was revoked last year due to the Boothole vulnerability. Wide scale delivery of the revocation file (dbx) by Windows Update, and likely some Linux distros, has been postponed but is expected to happen in Q2/Q3 2021. This will render shim unloadable on UEFI Secure Boot enabled systems with a recent dbx (revocation file), and means those systems won't boot current Fedora installation media at all. Fedora's shim 15.3 and GRUB 2.06 have fixes and enhancements, including a new SBAT generation based revocation regime needed to address the limitations of dbx based revocation.
Essentially three things are needed at once: security fixes and enhancements for both shim and grub, and they need to be signed with new keys.
The new versions are expected to land in Rawhide and Fedora 34 updates-testing this week.
Replaces bug 1883609.
SBAT, generation based revocation
Proposed as a Blocker for 34-final by Fedora user chrismurphy using the blocker tracking app because:
Basic: All release-blocking images must boot in their supported configurations. UEFI Secure Boot is an explicitly supported firmware type/mode.
Final: Shim and GRUB are Critical Path packages used on install media and needed for booting the install media when UEFI Secure Boot is enabled. The problem cannot be fixed with an update, we need it on media in order to boot from it. And the problem/bug severity is high.
+3 in https://pagure.io/fedora-qa/blocker-review/issue/310 , marking accepted.
Peter - where are we with this? This is an accepted F34 Final blocker, and Final freeze is coming up April 6. I'd like us to be out in front of accepted blockers at this point. Thanks!
FEDORA-2021-cab258a413 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-cab258a413
FEDORA-2021-f5540ef3d6 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f5540ef3d6
Availablity of updated shim answers needinfo I think :)
FEDORA-2021-cab258a413 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-cab258a413`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cab258a413
See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
New shim fails to boot with SecureBoot enabled, at least on some hardware: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cab258a413#comment-1978552
Adam has a potential fix upstream: https://github.com/rhboot/shim/pull/362
Setting status to POST.
So in testing, I discovered a bug in this version of shim:
The known practical effect of the bug is that if Secure Boot is enabled at the firmware level but signature validation is disabled at the mok level, the system will not boot. With the previous shim build it displayed the message "Booting in insecure mode" for two seconds, then booted; with this version of shim it shows "Bootloader has not verified loaded image. System is compromised. halting." and shuts down.
The bug also affects another case (the "MokDBState" variable), but I don't know what the practical consequence of that variable not being respected is. If anyone does, it would be useful to know.
According to Javier, Dell "Sputnik" (developer edition) laptops ship in the affected state from the factory. That is indeed exactly the laptop I have. So we can at least say, AIUI: any Fedora UEFI install on a Dell developer edition laptop with default factory configuration will stop booting after installing this update. Also, I believe, UEFI booting install media built with this version of shim on Dell developer edition laptops with default factory configuration will fail.
We don't know what (if any) other systems shipped in this state, how many (if any) other people are likely to have got into it manually (though I'd guess that number would be small).
pjones is working on a build of shim with the bug fixed "right now". It will then have to go through the SB signing process, which takes a few days I believe. I think if that all goes smoothly we should be able to pull in the fixed build without delaying the release, but if not, we may have to make a decision whether this bug is significant enough to delay the release for, or whether we should just accept it and release with it broken.