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. References: Replaces bug 1883609. SBAT, generation based revocation https://github.com/rhboot/shim/blob/main/SBAT.md
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: https://github.com/rhboot/shim/pull/362 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.
OK, update on status here: after I found that bug, cmurf found two others, one that breaks boot on early Intel Macs (with initial EFI, not UEFI, firmware) and one that caused an apparently non-fatal message on boot of some other systems. There is now an unsigned build which is tested to fix these bugs: https://koji.fedoraproject.org/koji/buildinfo?buildID=1735515 we would need a signed build to include in the release, however. pjones, is there an update on what build(s) is/are in for signing, and what the expected turnaround time will be? Note there is also a single boot failure with SB enabled reported in the Test Day results, by geraldosimiao: https://testdays.fedoraproject.org/events/111 but we have no details as yet on what went wrong.
Fedora 34 Workstation Beta 1.3 also fails to boot with secure boot enabled on Thinkpad X1 Carbon Gen 9 with BIOS version 1.23.
nh: can you please test with a recent nightly? Beta does not have the newer build under discussion here, it has the same one as F33 (IIRC). You can get the current nightly at https://kojipkgs.fedoraproject.org/compose/branched/Fedora-34-20210420.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-34-20210420.n.0.iso . thanks!
Adam Williamson: Same problem: fails to boot with secure boot enabled.
Can you try either of these images? https://fedorapeople.org/groups/qa/test_days/ Those are the only two right now that have shim-15.4 on it. Another possibility is that there's a grub 2.06 bug that nh's Thinkpad X1 is running into. Does that computer boot a Fedora 33 ISO?
Chris Murphy: - I'll try and report (Downloading now). - Same problem with Fedora 33 iso: fails to boot with secure boot enabled; Sidenote: all of the tried iso's boot / install fine without secure boot.
Chris Murphy: of the two iso's in the provided link, I tried the Workstation one: - It boots flawlessly! The output of "mokutil --sb-state" is: "SecureBoot enabled". Thanks a lot for all your work! If needed I'll be willing to test other things tomorrow from 20:00 UTC.
welp, that's another reason we need the fixed shim, I guess...thanks for the info.
Clearing needinfo as we now have a new signed build in bodhi
I did check the fix for my Dell issue, and cmurf confirmed the fix for his Intel Mac issue, and so far as the bug description goes, new bootloaders certainly are in RC2.
FEDORA-2021-cab258a413 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
I still have this issue Dell Precession 7530 Developer Edition. Security Boot on - black screen without errors Security Boot off - "The Matrix" screen Version-Release number of selected component (if applicable): I tested Fedora 34 Release Fedora 34 RC 1.1 Fedora 34 RC 1.2 Fedora 34 nightly from 24.04 Fedora 34 Beta with updated shim to 15.4-4 This shim versions does not boot shim 15.4-3 shim 15.4-4 Steps to Reproduce: 1. Boot Fedora 34 from USB or installed system 2. Update shim 15.8 to 15.4-4 on Fedora 34 Beta 1.3 3. Actual results: By default, the system boots with \EFI\fedora\shimx64.efi. In Bios i can create Boot Option with \EFI\fedora\grubx64.efi and Fedora boot from USB Live or SSD. I opened a new bug report because I didn't know what to write here. https://bugzilla.redhat.com/show_bug.cgi?id=1954245 Sorry.