EFI chainloader no longer uses shim lock protocol
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
grub2 (Ubuntu) |
Invalid
|
Low
|
Unassigned | ||
Eoan |
Invalid
|
Low
|
Unassigned |
Bug Description
GRUB versions pre-eoan contain modifications to the EFI chainloader command (grub-core/
This modification was dropped in the GRUB update in eoan (2.04) - the EFI chainloader command now always uses the LoadImage() and StartImage() EFI boot services, which requires a bootloader to be verified using a signature enrolled in the UEFI db. It's no longer possible to chainload another bootloader that has to be verified by a signature in the MOK db or shim's built-in vendor certificate.
I'm not sure if this is a deliberate change or an oversight.
description: | updated |
summary: |
- EFI chainloader no longer uses shim lock API + EFI chainloader no longer uses shim lock protocol |
tags: | added: rls-ee-incoming |
Changed in grub2 (Ubuntu): | |
importance: | Undecided → Low |
tags: | removed: rls-ee-incoming |
tags: | added: id-5d9f73922b5eff52fd6b7040 |
Changed in grub2 (Ubuntu): | |
status: | Incomplete → Invalid |
Changed in grub2 (Ubuntu Eoan): | |
status: | Incomplete → Invalid |
After further discussion with Chris; seems like this might have been a misunderstanding, looking at two different source trees for the software.
Chris; can you please confirm whether we've reached consensus on the state of the chainloader code for SB? From my read, the patches look to be properly applied, and chainloading Windows certainly works for me here.