Differences Between grubx64 and shimx64

1. Overview

In the UEFI boot process, grubx64.efi and shimx64.efi are two EFI software that serve different functions. The primary bootloader is grubx64.efi, which loads the Linux kernel, while shimx64.efi is a first-stage bootloader that assures Secure Boot compatibility. Understanding the differences between these two files is essential for setting and debugging the boot process on UEFI-based systems.

In this tutorial, we’ll explore the differences between grubx64.efi and shimx64.efi.

2. What Is grubx64.efi?

The grubx64.efi file is the primary component of the 64-bit UEFI version of the GRUB 2 bootloader, and it displays a menu that lets users choose between operating systems or kernel versions. The system usually stores its configuration in /boot/grub/grub.cfg, where it defines boot entries and parameters. GRUB is highly versatile, supporting multi-boot setups, chainloading other bootloaders, and providing a command-line interface for troubleshooting and customization.

Furthermore, on UEFI systems where Secure Boot is either disabled or not enforced (e.g., when using custom keys or self-signed bootloaders), grubx64.efi is frequently the default bootloader, which is widely used in Linux distributions due to its robustness and versatility.

3. What Is shimx64.efi?

shimx64.efi is an EFI application that functions as a first-stage bootloader for systems with Secure Boot enabled. Additionally, shimx64.efi works within the constraints of Secure Boot, which requires all bootloaders and kernels to be signed with a trusted Microsoft key.

shimx64.efi ensures that the boot process meets Secure Boot requirements, resulting in a secure environment for loading the operating system. shimx64.efi achieves this by checking the signature of grubx64.efi before chainloading it, ensuring that only trustworthy software is executed throughout the boot process.

4. Differences Between shimx64.efi and grubx64.efi

Understanding the differences in the functions, dependencies, and behaviors of these components is essential for configuring or troubleshooting UEFI-based Linux systems.

4.1. Role in the Boot Process

The main bootloader is grubx64.efi, which loads the Linux kernel and initrd. It’s in charge of providing the boot menu, loading the operating system, and accepting user input. However, shimx64.efi serves as a first-stage bootloader, ensuring Secure Boot compatibility. It doesn’t load the kernel directly, but rather chainloads grubx64.efi.

Finally, when Secure Boot is enabled, shimx64.efi is loaded by the UEFI firmware first, then, grubx64.efi is verified and loaded. This two-stage approach ensures trust, signs the bootloader and kernel, and prevents tampering.

4.2. Secure Boot Compatibility

grubx64.efi doesn’t support Secure Boot by default. Thus, the UEFI firmware won’t load grubx64.efi in a Secure Boot-enabled scenario unless a trusted key signs it. However, developers designed shimx64.efi specifically for Secure Boot. Moreover, most UEFI firmware implementations trust it because a Microsoft key signs it. Finally, it also verifies that grubx64.efi carries a valid signature:

$ sbverify --list /boot/efi/EFI/ubuntu/shimx64.efi
$ sbverify --list /boot/efi/EFI/ubuntu/grubx64.efi

In this example, we use the sbverify program to confirm the signatures of both files. The result will display the validity of the signatures. While grubx64.efi should have a signature that shimx64.efi trusts, shimx64.efi would have a legitimate Microsoft signature.

4.3. Configuration and Flexibility

The /boot/grub/grub.cfg file provides extensive configuration options for grubx64.efi. It can boot various operating systems, chainload other bootloaders, and offer a command-line interface to expert users. In contrast, shimx64.efi requires little setting. Its main function is to check and chainload grubx64.efi. It doesn’t offer the same degree of freedom as GRUB:

$ sudo nano /etc/default/grub
$ sudo update-grub

In this example, we configure GRUB by modifying the /etc/default/grub file, then we update the settings using the update-grub command. In addition, shimx64.efi doesn’t provide this amount of customization because its job is confined to assuring Secure Boot compatibility.

4.4. Signature Verification

In a Secure Boot-enabled scenario, the system administrator must sign grubx64.efi separately. Either UEFI firmware or shimx64.efi must trust this signature. Moreover, shimx64.efi verifies grubx64.efi’s signature to ensure it hasn’t been tampered with. If the signature isn’t correct, shimx64.efi won’t load grubx64.efi.

For example, attempting to boot an unsigned grubx64.efi on a Secure Boot-enabled system will result in a boot failure:

$ sbverify --list /boot/efi/EFI/ubuntu/grubx64.efi

In this example, we use the sbverify tool to verify the signature of grubx64.efi. Additionally, we’ll need to use a trusted Microsoft key to sign grubx64.efi if the signature is wrong or absent.

5. Conclusion

In this article, we explored the roles of grubx64.efi and shimx64.efi, which have different but complementary functions in the UEFI boot process. grubx64.efi is the primary bootloader that loads the Linux kernel, while shimx64.efi serves as a first-stage bootloader that ensures Secure Boot compatibility.

Finally, by following the guidelines and troubleshooting tips in this article, we can effectively manage and configure grubx64.efi and shimx64.efi on our Linux system, resulting in a smooth and secure boot process.