From: Avnish Chouhan <avnish@linux.ibm.com>
To: mchang@suse.com
Cc: grub-devel@gnu.org, Daniel Kiper <daniel.kiper@oracle.com>
Subject: Re: [PATCH] efi/sb: Fix boot failure when shim validation is disabled
Date: Thu, 11 Sep 2025 17:55:15 +0530 [thread overview]
Message-ID: <c77ef22bf969885387ebccd9e4b280b2@linux.ibm.com> (raw)
In-Reply-To: <mailman.277.1757320267.1172.grub-devel@gnu.org>
On 2025-09-08 14:01, grub-devel-request@gnu.org wrote:
> Message: 4
> Date: Mon, 8 Sep 2025 16:30:20 +0800
> From: Michael Chang <mchang@suse.com>
> To: The development of GNU GRUB <grub-devel@gnu.org>
> Subject: [PATCH] efi/sb: Fix boot failure when shim validation is
> disabled
> Message-ID: <20250908083020.352813-1-mchang@suse.com>
>
> When shim is switched to insecure mode via "mokutil
> --disable-validation", GRUB aborts midway when attempting to boot the
> kernel. With debug output enabled, the following error is shown:
>
> error: ../../grub-core/loader/efi/linux.c:219: cannot load image.
>
> The failure occurs because UEFI Secure Boot itself remains enabled, but
> the kernel is delegated to the firmware LoadImage() path since both the
> shim_load and shim_lock protocols appear to be absent. This delegation
> was introduced when GRUB gained support for shim_load, allowing kernels
> to take advantage of the LoadFile2 protocol. That logic assumed both
> shim protocols were missing.
>
> In fact, the shim protocols are still present but become invisible to
> GRUB because probing in the shim verifier is skipped. This happens
> because grub_efi_get_secureboot() considers MokSBState. When users
> disable shim validation, Secure Boot is detected as "off" and as a
> result the shim protocols are never processed.
>
> This patch fixes the issue by introducing
> grub_efi_get_secureboot_real(), which allows bypassing MokSBState when
> deciding whether to set up the shim verifier. This ensures that the
> shim
> protocols are still correctly discovered and used even if shim is
> placed
> into insecure mode. At the same time, grub_efi_get_secureboot()
> continues to preserve the logic that matches the Linux kernel
> implementation, keeping the two consistent.
>
> Signed-off-by: Michael Chang <mchang@suse.com>
> ---
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
next parent reply other threads:[~2025-09-11 12:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.277.1757320267.1172.grub-devel@gnu.org>
2025-09-11 12:25 ` Avnish Chouhan [this message]
2025-11-24 8:57 [PATCH] efi/sb: Fix boot failure when shim validation is disabled Michael Chang via Grub-devel
2025-11-24 11:33 ` Daniel Kiper
2025-11-25 4:42 ` Michael Chang via Grub-devel
-- strict thread matches above, loose matches on Subject: below --
2025-09-08 8:30 Michael Chang via Grub-devel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c77ef22bf969885387ebccd9e4b280b2@linux.ibm.com \
--to=avnish@linux.ibm.com \
--cc=daniel.kiper@oracle.com \
--cc=grub-devel@gnu.org \
--cc=mchang@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.