0

I am attempting to create an ultimate USB Stick that will contain 2 Linux Distros, Windows and a Plethora of ISOs.

So far I have installed Windows, Ubuntu and Fedora Silverblue to a disk (I've been testing in an VM to make things quicker). In the UEFI boot menu of the machine, I can see all of the options and boot any of them successfully. UEFI BIOS Showing all options

From within either the Fedora or Ubuntu GRUB menu, I can boot Windows but they are both unable to boot one-another. enter image description here

Since I eventually want to also boot ISO files, I need to be able to load other Linux installs from GRUB.

Things I Tried:

Disable Secure Boot:

This does work however I do not want to do this because I want to be able to use this on other people's machines and I may not feel happy disabling their secure boot.

Chainloading:

GRUB loads Windows via chainloader so I thought that I would be able to do the same with Linux.

If I chainloader /EFI/ubuntu/grubx64.efi (from Fedora's GRUB menu) then I get the same shim error.

If I chainloader /EFI/ubuntu/shimx64.efi (from Fedora's GRUB menu) then I get as far as Ubuntu's GRUB menu - although I still get a shim error when actually trying to boot Ubuntu.

If I understand correctly,

If I understand correctly, the shimx64.efi is what actually gets loaded by the UEFI BIOS. Does this file only contain the secure boot information for a single kernel?

Is there any way that I can get the UEFI to load the shimx64.efi again when I choose to chainload to the other GRUB menu?

TLDR; Could someone explain to me about shimx64.efi and if it is possible to dual-boot two Linux distros from the same GRUB menu while Secure Boot is enabled.

Many thanks, Will

1 Answer 1

1

If I understand correctly, the shimx64.efi is what actually gets loaded by the UEFI BIOS. Does this file only contain the secure boot information for a single kernel?

Almost but not quite correct. A version of the shim is signed by Microsoft for each distribution, and the shim includes the Secure Boot public key of the distribution it belongs to. When the shim is used, it temporarily (non-persistently) adds the distribution's Secure Boot key to the list of keys allowed to boot the system. Optionally the shim can add a Machine Owner's Key (MOK) too.

So, when you load Fedora's shimx64.efi, it makes it possible for Secure Boot to accept things signed by Fedora. Then it loads grubx64.efi, which is signed by Fedora and now acceptable to the Secure Boot firmware. When grubx64.efi loads Fedora's kernel, the kernel file is signed by Fedora and so Secure Boot allows the kernel code to be executed.

If you wanted to build your custom kernel, you would have to create a MOK and sign your custom kernel with it. Also, if you wanted to build custom or third-party kernel modules, you would have to sign them with the MOK too, because one part of the Secure Boot "contract" is that no unsigned kernel code must be allowed. So the bootloader must check the kernel's signature, and the kernel must check the signature of each module when Secure Boot is enabled.

You won't be able to sign anything with the distribution's Secure Boot key, because that requires the private part of the distribution's Secure Boot key - which is presumably kept extremely safe by the people responsible for the security of the respective distribution.

And installing your MOK on other peoples' machines would be almost as bad as disabling their Secure Boot, as it would then enable you to boot anything on their systems.

Apparently chainloading another copy of shim after one shim is already loaded should work in theory, but the shim's source code comments indicate it's not exactly trivial.

1
  • Thank you. I looked at the comments about chainloading and I managed to get Fedora to boot from Ubuntu's GRUB by chainloading the fallback (ESP/Boot/fbx64.efi). I couldn't find a similar file to do the same thing with ISO installers though unfortunately. Jul 25, 2022 at 12:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .