EFI chainloader no longer uses shim lock protocol

[Chris Coulson]

GRUB versions pre-eoan contain modifications to the EFI chainloader command (grub-core/loader/efi/chainloader.c) which allow a chainloaded bootloader to be verified using the shim lock EFI protocol (which validates an image against signatures enrolled in the UEFI db, MOK db and shim's built-in vendor certificate). The verified bootloader is subsequently executed directly without the use of the LoadImage() and StartImage() EFI boot services.

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.

[Mathieu Trudel-Lapierre (cyphermox)]

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.

[Mathieu Trudel-Lapierre (cyphermox)]

The code does look like it will chainload via shim:

linuxefi_secure_validate() runs, checks that the image is valid against firmware stores and the MokList.

Then

grub_cmd_chainloader -> (grub_linuxefi_secure_validate() find the image valid) -> grub_secureboot_chainloader_boot() -> handle_image() [ read image header, identify relocations, find entry point, etc.] -> efi_call_2 (entry point) -> Image is started