UEFI: what happens when booting the system

Updated

This article describes the operations performed when booting a UEFI system until the Grub menu stored on the EFI partition present on the hard disk is displayed.

For demonstration purposes, we will use a QEMU/KVM x86_64 system loaded with the RHEL8.5 DVD.


Table of contents


Normal workflow

1. Initial UEFI boot order

With QEMU/KVM, the UEFI firmware enables the following boot devices in order of priority:

UEFI Misc Device
UEFI QEMU DVD-ROM QM00001

The UEFI firmware will attempt to execute the (EFI Partition)/EFI/BOOT/BOOTX64.EFI binary. If it doesn't find it, it will continue to the next device.

2. Installation from the DVD

The first device UEFI Misc Device is the hard disk, which is initially blank, hence doesn't have any EFI partition.
This will hence lead to booting on the next device, UEFI QEMU DVD-ROM QM00001, which is currently loaded with a RHEL8.5 DVD, which has a EFI partition.

Due to having found the (EFI Partition)/EFI/BOOT/BOOTX64.EFI binary on the DVD, the latter executes.

BOOTX64.EFI is Shim executable shipped by RHEL8.
Shim executable searches in turn for grubx64.efi (Grub2) in current directory (which is (EFI Partition)/EFI/BOOT) and executes it.
Finally Grub2 executes and presents the installation menu stored as (EFI Partition)/EFI/BOOT/grub.cfg.

The installation then occurs.
Later shim-x64 and grub2-efi packages are installed.
Finally as a post-installation task, Anaconda creates a UEFI boot entry named Red Hat Enterprise Linux which points to hard disk's (EFI Partition)/EFI/redhat/shimx64.efi executable.

Once installation is finished, we have the following UEFI boot order:

Red Hat Enterprise Linux
UEFI Misc Device
UEFI QEMU DVD-ROM QM00001

3. Boot on the hard disk

The new first device is now Red Hat Enterprise Linux entry, which contains a path to a specific location:

HD(1,GPT,2377f198-cd11-4fa5-abf7-355837ae125b,0x800,0x12c000)/File(\EFI\redhat\shimx64.efi)

Due to this, instead of trying to search for the (EFI Partition)/EFI/BOOT/BOOTX64.EFI binary, the UEFI firmware just boots the above entry.

shimx64.efiis Shim executable shipped by installed shim-x64 package.
Shim executable searches for grubx64.efi (Grub2) in current directory (which is (EFI Partition)/EFI/redhat) and executes it.
Finally Grub2 executes and presents the hard disk menu stored as (EFI Partition)/EFI/redhat/grub.cfg.


Firmware recovery

Let's say we now delete the Red Hat Enterprise Linux entry to have the default UEFI entries again.

Usually deletion is performed from the UEFI firmware itself or through using the efibootmgr command, as shown in the example below:

  1. List the current boot entries

    # efibootmgr
    BootOrder: 0002,0001,0000
    Boot0000* UiApp
    Boot0001* UEFI Misc Device
    Boot0002* Red Hat Enterprise Linux
    
  2. Delete the entry

    # efibootmgr -B -b 0002
    

1. Boot

Upon rebooting, we won't have the Red Hat Enterprise Linux entry anymore, but the following UEFI boot order:

UEFI Misc Device
UEFI QEMU DVD-ROM QM00001

The UEFI firmware will attempt to execute the (EFI Partition)/EFI/BOOT/BOOTX64.EFI binary. If it doesn't find it, it will continue to the next device.
The first device UEFI Misc Device is the hard disk, which is not blank anymore but contains a EFI partition which has file /EFI/BOOT/BOOTX64.EFI.
Hence the UEFI boot loader finds (EFI Partition)/EFI/BOOT/BOOTX64.EFI binary and boots the latter.

2. Recovery

BOOTX64.EFI is Shim executable shipped by RHEL8.
Because Shim doesn't execute as shimx64.efi but BOOTX64.EFI, Shim searches for a fbx64.efi binary in current directory (which is /EFI/BOOT).
Due to finding the latter binary, it executes it to perform the recovery.

fbx64.efi is a special binary shipped by installed shim-x64 package.
fbx64.efi searches for all directories in /EFI containing a BOOTX64.CSV file. On RHEL systems, the file is /EFI/redhat/BOOTX64.CSV.
Upon finding search file, it creates an entry in UEFI firmware based on the file content:

  • Entry name: Red Hat Enterprise Linux
  • Boot loader: shimx64.efi

Finally it sets the new entry as highest priority entry.

3. Boot on new entry

Finally it boots on the entry it just created, /EFI/redhat/shimx64.efi.

shimx64.efiis Shim executable shipped by installed shim-x64 package.
Shim executable searches for grubx64.efi (Grub2) in new current directory (which is (EFI Partition)/EFI/redhat) and executes it.
Finally Grub2 executes and presents the hard disk menu stored as (EFI Partition)/EFI/redhat/grub.cfg.


Avoiding Recovery from taking place

In some rare cases, the administrator may want to avoid having the Recovery code execute when booting on BOOX64.EFI binary.
Since BOOTX64.EFI relies on the presence of fbx64.efi executable to perform the recovery, there is no other way than deleting the file.
Unfortunately, the file will be pushed to the EFI partition upon shim-x64 package update or re-installation.

The solution is then to create a custom service that will execute as soon as (EFI Partition)/EFI/BOOT/fbx64.efi gets created to delete the file.
This can be done through creating the following systemd service units:

  • Unit /etc/systemd/system/delete_efi_fallback_kcs6645591.path in charge of monitoring changes on EFI partition

    # Unit making sure UEFI Recovery code never executes (KCS 6645591)
    # https://access.redhat.com/articles/6645591
    [Path]
    PathChanged=/boot/efi/EFI/BOOT
    
    [Install]
    WantedBy=default.target
    
  • Unit /etc/systemd/system/delete_efi_fallback_kcs6645591.service in charge of deleting the file

    # Unit making sure UEFI Recovery code never executes (KCS 6645591)
    # https://access.redhat.com/articles/6645591
    [Service]
    Type=oneshot
    ExecStart=-/bin/rm /boot/efi/EFI/BOOT/fbx64.efi
    

Upon enabling the delete_efi_fallback_kcs6645591.path unit, the file will be automatically deleted upon shim-x64 package update or re-installation:

# systemctl daemon-reload
# systemctl enable delete_efi_fallback_kcs6645591.path --now

Note: This approach will work only when OS is running and systemd can execute the created unit. If system was for example restored from backup that contained the fbx64.efi binary, this binary needs to be removed before booting in system restored in this way.

SBR
Category
Components
Article Type