2

After installing Ubuntu, there are several *.efi files inside /efi/UBUNTU/ of EFI system partition:

  • GRUBX64.EFI
  • MOKMANAG.EFI
  • SHIMX64.EFI
  • mmx64.efi
  • fwupx64.efi

But UEFI Specification 2.7 says in the section "13.3.1.3 Directory Structure":

There must also only be one executable EFI image for each supported processor architecture in each vendor subdirectory. This guarantees that there is only one image that can be loaded from a vendor subdirectory by the EFI Boot Manager. If more than one executable EFI image is present, then the boot behavior for the system will not be deterministic.

I would make clear the boot behavior of GRUB's 5 EFI executable files.

Intron BBS
  • 21
  • 3
  • I can confirm your interpretation of the specification. I would _love_ if you could send this exact question to the http://uefi.org/FWOSForum mailing list. (This question may end up closed if not moved to SuperUser, since it is not directly related to programming.) – unixsmurf May 03 '18 at 09:16
  • Though, There are many images present, they are usually used in some order. In this case I understand SHIMX64.EFI shall be started after POR and then Shim starts GRUBX64.EFI. – rk1825 May 18 '18 at 14:01

2 Answers2

1

The UEFI firmware will normally look into the /boot/efi/EFI/BOOT/ folder for the appropriate EFI executable. The name of the executable it looks for depends on the architecture of your system. For a x86_64 architecture, the file is BOOTX64.EFI

This file is actually a copy of one of the EFI executables that lie in the /boot/efi/EFI/ubuntu/ folder. In my case /boot/efi/EFI/BOOT/BOOTX64.EFI is a copy of /boot/efi/EFI/ubuntu/shimx64.efi.

See UEFI boot: how does that actually work, then? and The EFI System Partition and the Default Boot Behavior for a more detailed explanation.

To understand why there are all these other EFI executables in /boot/efi/EFI/ubuntu/, see SecureBoot on the ubuntu wiki.

The Quark
  • 111
  • 3
0

  1. I dont know the UEFI spec well enough to answer the question of why. But from what I do know of how UEFI boot works, I don't see why there should be this limitation at all. Given the power of UEFI it does not seem necessary.

  2. The binary in \EFI\BOOT\BOOTX64.EFI is the fallback that is used if nothing else can be found. Typically if you want to make a USB stick that you can carry from PC to PC you would make that. Of course BOOTX64.EFI can be a copy of any valid boot loader. Early PC's would put a copy of the MS bootloader there. Ubuntu install might put a copy of its shim there. ETC.

  3. If Secure Boot is turned on then UEFI will refuse to run an .efi binary that is not properly signed. Of the Binaries you give I would expect that only SHIM would be properly signed and so the others will not run.

  4. UEFI attempts to boot things in BOOT ORDER. The boot order specifies in what order to try the NVRAM UEFI variables Boot0000, Boot0001, etc. (Not all of whom have to exist) So the BootOrder variable would contain a list such as 07 0002 0004 000F. This tells UEFI to try Boot0007 then after that returns (which it should not if it succeeds in booting the os) next to try Boot0002 etc. "Try Boot####" means look in the contents of that variable and run the relevant code. The 'relevant code' will depend on whether the boot is over the network, from a BIOS MBR disk, from a CD or from a ESP. If from a ESP the variable in question will probably contain a path name which will specify exactly which .efi file to run. In your case it will say to run \ubuntu\shimx64.efi shim will then run grubx64.efi from the same directory it was started from (\ubuntu here) and grubx64.efi will either show a menu or search the hard drive(s) for the vmlinuz (or other ) OS kernel to load and run.

Given that UEFI can do all that sort of thing, I don't see why the spec would limit the contents of a directory on the ESP to only one EFI file. To do so would seem to lead to many needless directories, and Sub Directories.

Greg
  • 35
  • 5