On Wed, Feb 11, 2026 at 08:17:01PM +0100, Ard Biesheuvel wrote: > Hello Michael, > > On Mon, 8 Dec 2025, at 11:03, Michael Chang via Grub-devel wrote: > > From: Michael Chang via Grub-devel <[email protected]> > > > > 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:grub_arch_efi_linux_boot_image:227: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_loader and shim_lock protocols appear to be absent. This delegation > > was introduced when GRUB gained support for shim_loader, 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 missing 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 problem by introducing > > grub_efi_get_secureboot_real(), which bypasses MokSBState when deciding > > whether to set up the shim protocols. This allows the shim protocols to > > be correctly discovered and used even when shim is placed into insecure > > mode. Once the shim protocols are found, the boot path proceeds as > > intended, either through the legacy fallback path or through the shim > > loader override, both of which steer away from executing the firmware > > LoadImage() path directly. > > > > At the same time, grub_efi_get_secureboot() retains the behavior that > > matches the Linux kernel implementation, leaving the existing shim_lock > > and lockdown verifier registration unchanged and consistent. > > > > Signed-off-by: Michael Chang <[email protected]> > > --- > > grub-core/kern/efi/init.c | 6 ++++++ > > grub-core/kern/efi/sb.c | 41 ++++++++++++++++++++++++++++++--------- > > include/grub/efi/sb.h | 12 +++++++++++- > > 3 files changed, 49 insertions(+), 10 deletions(-) > > > > I ran into the same issue today. > > Your fix looks correct to me, but perhaps a bit convoluted? Before finding > your patch, I fixed it locally by just adding a 'bool' argument to > grub_efi_get_secureboot (), and let the caller decide whether the MOK state > should be taken into account. IOW, I don't think there is necessarily a > global 'skip_moksbstate' state that decides this for all cases.
Sorry for the late reply. I was out for the Lunar New Year's break. Actually I'm a bit confused by the statement that skip_moksbstate is a global state for all cases. It is actually a bool argument to grub_efi_get_secureboot_real() where grub_shim_lock_protocol_setup() is the only caller. And hence that will leave rest of the callers of grub_efi_get_secureboot() unchanged. I think that would make the intention more obvious, as the newly added function grub_shim_lock_protocol_setup() is the only place needs to adapt to this change. > > In any case, it would be nice to get this fixed so mainline GRUB works as > expected when executing under a signed SHIM. > > Acked-by: Ard Biesheuvel <[email protected]> Thank you. I'll add your Acked-by to next revision. Thanks, Michael > > _______________________________________________ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
