Bug 1938630 - include new bootloaders on Fedora 34 install media so UEFI Secure Boot enabled systems can boot from them
Summary: include new bootloaders on Fedora 34 install media so UEFI Secure Boot enable...
Status: POST
Alias: None
Product: Fedora
Classification: Fedora
Component: shim
Version: 34
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
Depends On: 1784546 1784548
Blocks: F34FinalBlocker, FinalBlocker
TreeView+ depends on / blocked
Reported: 2021-03-15 01:58 UTC by Chris Murphy
Modified: 2021-04-09 18:42 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github rhboot shim pull 362 0 None open Don't set user_insecure_mode and ignore_db in import_one_mok_state 2021-04-09 17:25:03 UTC

Description Chris Murphy 2021-03-15 01:58:20 UTC
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

Comment 1 Fedora Blocker Bugs Application 2021-03-15 02:04:37 UTC
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.

Comment 2 Adam Williamson 2021-03-15 16:08:01 UTC
+3 in https://pagure.io/fedora-qa/blocker-review/issue/310 , marking accepted.

Comment 3 Adam Williamson 2021-03-27 01:00:23 UTC
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!

Comment 4 Fedora Update System 2021-04-06 19:47:45 UTC
FEDORA-2021-cab258a413 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-cab258a413

Comment 5 Fedora Update System 2021-04-06 19:47:50 UTC
FEDORA-2021-f5540ef3d6 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f5540ef3d6

Comment 6 Chris Murphy 2021-04-07 17:54:58 UTC
Availablity of updated shim answers needinfo I think :)

Comment 7 Fedora Update System 2021-04-07 18:15:53 UTC
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.

Comment 8 Ben Cotton 2021-04-09 17:25:06 UTC
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.

Comment 9 Adam Williamson 2021-04-09 18:42:44 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.