[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Debian+Ubuntu dual boot with UEFI secure boot and shim+grub



Hello,

Here are the results of some tests I did in QEMU/KVM using OVMF with secure boot enabled.
Debian 12.4
Ubuntu 22.04
No additional keys are enrolled in MOK or secure boot db.

In the following tables, the "result" column contains the result of "linux" and "boot" grub commands.

1) Booting without chainloading

UEFI > shim > grub
grub> linux vmlinuz
grub> boot

shim   | kernel | result
------ | ------ | ------
debian | debian | linux, boot -> OK
debian | ubuntu | linux -> bad shim signature
ubuntu | ubuntu | linux, boot -> OK
ubuntu | debian | linux -> bad shim signature

As expected, the "linux" command fails to verify a "foreign" kernel.

2) Booting with chainloading

UEFI > shim#1 > grub#1
grub#1> chainloader shim#2
grub#2> linux vmlinuz
grub#2> boot

1st shim | 2nd shim | kernel | result
-------- | -------- | ------ | ------
debian   | ubuntu   | ubuntu | linux, boot -> OK
debian   | ubuntu   | debian | linux -> bad shim signature
ubuntu   | debian   | ubuntu | linux OK, boot -> Bootloader has not
         |          |        | verified image
ubuntu   | debian   | debian | linux OK, boot -> Bootloader has not
         |          |        | verified image

When booting Debian's shim and chainloading Ubuntu's shim, the behaviour is the same as if Ubuntu's shim is booted directly.

However when booting Ubuntu's shim and chainloading Debian's shim, the "linux" command loads either kernel without error but after the "boot" command the following lines are displayed:

 Bootloader has not verified image.
 System is compromised.  halting.

This message seems to be from shim in function exit_boot_services(). Note that it is displayed after the message "EFI Stub: UEFI Secure boot is enabled." which is from the kernel (without "quiet").

What could be wrong and cause this difference ?

PS: I received the following answer in #debian-efi, but it does not fully explain the above results:

Chainloading shims is not a valid use case. You can only load one shim in the boot process because there can only be one shim owning the GUID. And the 2nd shim can't unload the first shim's implementation or override it. But I'd expect it to fail to verify the kernel, not complain at the ExitBootServices stage because it should be using Ubuntu's shim to verify the kernel.


Reply to: