Comment 22 for bug 1845289

Revision history for this message
Ivan Larionov (xeron-oskom) wrote :

Take a look at this diff between disco and eoan:

--- grub2-2.02+dfsg1/grub-core/loader/efi/linux.c 2019-10-29 00:23:53.000000000 +0000
+++ grub2-2.04/grub-core/loader/efi/linux.c 2019-10-29 00:10:44.000000000 +0000
@@ -23,6 +23,7 @@
 #include <grub/efi/efi.h>
 #include <grub/efi/pe32.h>
 #include <grub/efi/linux.h>
+#include <grub/efi/sb.h>

 #define SHIM_LOCK_GUID \
  { 0x605dab50, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23} }
@@ -40,6 +41,13 @@
   grub_efi_shim_lock_t *shim_lock;
   int status;

+ if (! grub_efi_secure_boot())
+ {
+ grub_dprintf ("linuxefi", "secure boot not enabled, not validating");
+ return 1;
+ }
+
+ grub_dprintf ("linuxefi", "Locating shim protocol\n");
   shim_lock = grub_efi_locate_protocol(&guid, NULL);
   grub_dprintf ("secureboot", "shim_lock: %p\n", shim_lock);
   if (!shim_lock)

if grub_efi_secure_boot() returns 0 then grub_linuxefi_secure_validate() prints "secure boot not enabled" but returns 1? Doesn't sound right. Should return 0 I guess?

And if grub_linuxefi_secure_validate() returns 1 then this chainloader code switches to secureboot:

  rc = grub_linuxefi_secure_validate((void *)((grub_addr_t) address), fsize);
  grub_dprintf ("chain", "linuxefi_secure_validate: %d\n", rc);
  if (rc > 0)
    {
      grub_file_close (file);
      grub_loader_set (grub_secureboot_chainloader_boot,
         grub_secureboot_chainloader_unload, 0);
      return 0;
    }
  else if (rc == 0)
    {
      grub_load_and_start_image(boot_image);
      grub_file_close (file);
      grub_loader_set (grub_chainloader_boot, grub_chainloader_unload, 0);

      return 0;
    }

resulting in trying to secure boot windows efi image instead of just calling grub_load_and_start_image().