0

I have a workstation with an UEFI firmware and a disk with a GPT type partition table. According to EFI Boot Manager, the the system is instructed to boot from UUID 7e169454-1df0-40bf-9c63-0f6b094c1e15:

# efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000
Boot0000* debian        HD(1,GPT,7e169454-1df0-40bf-9c63-0f6b094c1e15,0x800,0xee000)/File(\EFI\debian\grubx64.efi)
#

7e169454-1df0-40bf-9c63-0f6b094c1e15 is the first partition of the /dev/sdb disk with FAT32 file system:

# blkid /dev/sdb1
/dev/sdb1: UUID="DA79-BCEA" TYPE="vfat" PARTUUID="7e169454-1df0-40bf-9c63-0f6b094c1e15"
#

According to this UEFI guide, the UEFI spec requires, that UEFI is able to read the (GPT) partition table. Is this needed only during installing/editing the EFI Boot Manager? As I understand, the efibootmgr adds the start sector and end sector of the partition to the EFI Boot Manager entry. For example, based on the example above, my EFI Boot Manager entry contains the 0x800(2048 in decimal) and 0xee000(974848 in decimal) which match with the start and end sectors shown by the fdisk which reads those from the GPT:

# fdisk /dev/sdb

Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): i
Partition number (1-4, default 4): 1


     Device: /dev/sdb1
      Start: 2048
        End: 976895
    Sectors: 974848
       Size: 476M
       Type: EFI System
  Type-UUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93B
       UUID: 7E169454-1DF0-40BF-9C63-0F6B094C1E15

Does UEFI need the access to the partition table in order to populate the EFI Boot Manager with start and end sectors information?

Or maybe UEFI requires access to partition tables during each boot because it needs to find the partition matching the UUID? If I understand this UEFI guide correctly, then during the boot-up UEFI will initialize every peripheral in no particular order until it finds a partition matching that UUID. So in my example, it would read the 7e169454-1df0-40bf-9c63-0f6b094c1e15 from the EFI Boot Manager and then go through each block device and read their GPT until the partition with 7e169454-1df0-40bf-9c63-0f6b094c1e15 is found?

Martin
  • 7,516

1 Answers1

4

According to this UEFI guide, the UEFI spec requires, that UEFI is able to read the (GPT) partition table.

This is a specification requirement, so it means that while a particular UEFI firmware implementation may support other partition table formats too, every UEFI implementation must also support GPT in order to be compliant with the specification. So, an UEFI implementation on PC hardware will generally also support classic MBR partitioning, at least enough to recognize it. Apple's UEFI implementation may also support Apple's own old partitioning scheme, Oracle/Sun UEFI may also understand Solaris VTOC disklabels, and so on.

Is this needed only during installing/editing the EFI Boot Manager?

The EFI Boot Manager is built-in to the UEFI firmware. You don't "install" it, ever. With the efibootmgr command, you can edit its parameters which are stored in non-volatile memory (NVRAM) on the motherboard.

An UEFI firmware will need the capability to read a GPT partition table on every boot, unless the system has been installed using alternative partition table formats supported by that particular UEFI implementation.

The string HD(1,GPT,7e169454-1df0-40bf-9c63-0f6b094c1e15,0x800,0xee000) in efibootmgr output is not just any string: it is a concise human-readable representation of a UEFI hard drive media device path data structure. That data structure is how the data is actually stored in the NVRAM for the EFI Boot Manager.

The UEFI specification says (emphasised and split into paragraphs by me):

The boot manager must also support booting from a short-form device path that starts with the first element being a hard drive media device path (see Table77). The boot manager must use the GUID or signature and partition number in the hard drive device path to match it to a device in the system.

If the drive supports the GPT partitioning scheme the GUID in the hard drive media device path is compared with the UniquePartitionGuid field of the GUID Partition Entry (see Table18). If the drive supports the PC-AT MBR scheme the signature in the hard drive media device path is compared with the UniqueMBRSignature in the Legacy Master Boot Record (see Table13).

If a signature match is made, then the partition number must also be matched. The hard drive device path can be appended to the matching hardware device path and normal boot behavior can then be used. If more than one device matches the hard drive device path, the boot manager will pick one arbitrarily. Thus the operating system must ensure the uniqueness of the signatures on hard drives to guarantee deterministic boot behavior.

So the matching by the partition's unique UUID is the primary mechanism. The start & end sector information is just there to provide redundancy: any UEFI implementation is free to use it, or to ignore it.

The UEFI firmware might use the start & end sector information for e.g. further checks that the NVRAM information and the disk contents match each other. It would also allow the firmware to try and find the ESP partition by location if the disk's partition table seems to be damaged, resulting in a system that can be more robust against data errors. Each UEFI firmware implementer can decide for themselves if they'll want to use this extra information or not, and if they do, what will their overall strategy be.

A security-minded UEFI implementation might stop the boot process and report an error for any discrepancy, while an implementation designed for maximum reliability might try all combinations of the redundant information before failing, to maximize the chances of working around a single error in either the NVRAM or the partition table. A minimalist UEFI implementation might just stop with an error message if it fails to find a matching signature and completely ignore the extra information.

If you want to understand UEFI and its capabilities better, you should try using an UEFI shell. Some UEFI implementations (by e.g. Intel or Phoenix) have it as built-in; others (by AMI) have a specific option to run a shellx64.efi file if one is added to the root of your ESP (EFI System Partition). If all else fails, you can always place the .efi file of the shell onto your ESP and use efibootmgr to configure it as an additional boot menu item in EFI Boot Manager.

At the time of this writing, the newest pre-compiled version of UEFI shell available from the TianoCore project seems to be at: https://github.com/tianocore/edk2/releases/download/edk2-stable201911/ShellBinPkg.zip

telcoM
  • 96,466