How Linux Uses Shim Bootloader for Secure Boot

This article provides an overview of how Linux distributions natively support UEFI Secure Boot using a lightweight first-stage bootloader called "shim." It covers the chain of trust established from the motherboard firmware to the operating system kernel, the role of Microsoft's third-party signing authority, and how users can manage custom keys using the Machine Owner Key (MOK) architecture.

The Secure Boot Challenge in Linux

UEFI Secure Boot is designed to prevent unauthorized or malicious code from executing during the boot process. It achieves this by checking the cryptographic signature of boot components against trusted public keys stored in the motherboard's Non-Volatile RAM (NVRAM).

By default, virtually all modern PC hardware comes pre-loaded with the Microsoft UEFI Third-Party Marketplace Certificate Authority (CA) key. Motherboard vendors rarely include Linux distribution-specific keys in their firmware. To allow Linux distributions to boot out-of-the-box on standard hardware without requiring users to disable Secure Boot or manually import keys into the BIOS/UEFI, the Linux community developed the shim bootloader.

What Is the Shim Bootloader?

The shim bootloader is a small, vendor-neutral EFI application (typically distributed as shimx64.efi). Its primary function is to act as a bridge between the UEFI firmware and the primary Linux bootloader, such as GRUB 2.

Because it is relatively small and changes infrequently, Linux distributions can submit shim binaries to Microsoft to be signed with the widely pre-installed Microsoft Third-Party UEFI CA key. Once signed, the firmware treats the shim as trusted software.

The Secure Boot Execution Flow

When a computer with Secure Boot enabled powers on, Linux establishes a chain of trust through several sequential steps:

  1. Firmware to Shim: The UEFI firmware initializes and attempts to run the bootloader defined in the boot order. It checks the digital signature of shimx64.efi using the Microsoft key stored in its NVRAM database (db). Because the signature is valid, the firmware executes shim.
  2. Shim to Second-Stage Bootloader: Once in control, shim needs to load the primary bootloader (usually GRUB, named grubx64.efi). Shim carries the specific distribution's embedded public key (such as Canonical, Red Hat, or openSUSE). It uses this embedded key to verify the signature of grubx64.efi before executing it.
  3. GRUB to the Linux Kernel: GRUB reads its configuration and loads the Linux kernel (vmlinuz). GRUB uses the verification services provided by shim to check that the kernel image is signed by a recognized key.
  4. Kernel Lockdown: Once loaded, modern Linux kernels enter a restricted operation state often referred to as "Lockdown mode." This state restricts user-space access (even as the root user) from modifying running kernel memory, disabling kernel module signature checks, or performing direct hardware access that could circumvent Secure Boot guarantees.

The Machine Owner Key (MOK) System

While the embedded vendor key handles official distribution packages, users often need to load custom kernels or out-of-tree hardware drivers (such as proprietary GPU drivers or VirtualBox modules). To support this without compromising system security, shim integrates the Machine Owner Key (MOK) system.

The MOK architecture consists of two primary components:

Once a key is enrolled into the MOK database, shim stores it securely in NVRAM. During subsequent boots, shim will validate any binaries or modules signed with this user-generated key, enabling flexibility while preserving the integrity of the secure boot sequence.