efi: Set shim_lock_enabled even if validation is disabled

If validation has been disabled via MokSbState, secure boot on the
firmware is still enabled, and the kernel fails to boot.

This is a bit hacky, because shim_lock is not *fully* enabled, but
it triggers the right code paths.

Ultimately, all this will be resolved by shim gaining it's own image
loading and starting protocol, so this is more a temporary workaround.

Fixes: 6425c12cd (efi: Fallback to legacy mode if shim is loaded on x86 archs)

Cc: Peter Jones <pjones@redhat.com>
Cc: Michael Chang <mchang@suse.com>
Signed-off-by: Julian Andres Klode <julian.klode@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This commit is contained in:
Julian Andres Klode authored and Daniel Kiper committed 2023-12-05 15:28:39 +01:00
1 parent e35683317e
commit e60015f574
1 file changed
+8
+8
View File
@@ -95,6 +95,14 @@ grub_efi_get_secureboot (void)
if (!(attr & GRUB_EFI_VARIABLE_RUNTIME_ACCESS) && *moksbstate == 1) if (!(attr & GRUB_EFI_VARIABLE_RUNTIME_ACCESS) && *moksbstate == 1)
{ {
secureboot = GRUB_EFI_SECUREBOOT_MODE_DISABLED; secureboot = GRUB_EFI_SECUREBOOT_MODE_DISABLED;
/*
* TODO: Replace this all with shim's LoadImage protocol, delegating policy to it.
*
* We need to set shim_lock_enabled here because we disabled secure boot
* validation *inside* shim but not in the firmware, so we set this variable
* here to trigger that code path, whereas the actual verifier is not enabled.
*/
shim_lock_enabled = true;
goto out; goto out;
} }