How Debian Uses Shim-Signed for Secure Boot

Debian enables UEFI Secure Boot compatibility on modern PC hardware primarily through the shim-signed package. Because most computer motherboards ship exclusively with Microsoft's Certificate Authority (CA) keys embedded in their firmware, open-source distributions cannot directly boot signed kernels on locked hardware without relying on an intermediary. Debian solves this through a multi-stage chain of trust that starts with a Microsoft-signed first-stage bootloader and hands off execution to Debian's signed GRUB bootloader and Linux kernel.

The Secure Boot Trust Problem

When a UEFI system boots with Secure Boot enabled, the firmware verifies the cryptographic signature of the boot binary against its internal database (the Authorized Signature Database, or db). Almost all consumer hardware includes Microsoft's 3rd Party UEFI CA key in this database, but hardware manufacturers do not include Debian's private keys. To boot without forcing users to disable Secure Boot or manually import keys into the motherboard firmware, Debian must present a binary that Microsoft's embedded key recognizes.

The Role of the Shim Binary

The shim-signed package provides this bridge. It contains a small, specialized, first-stage bootloader (shimx64.efi on 64-bit x86 systems) developed collaboratively by multiple Linux distributions and submitted to Microsoft to be signed with their 3rd Party UEFI CA key.

When the machine powers on:

  1. The UEFI firmware validates the digital signature of shimx64.efi using the pre-installed Microsoft CA.
  2. Once validated, the firmware hands execution over to shim.

Debian's Embedded Certificate

Rather than booting the operating system directly, shim exists to validate and run the next component in the sequence: GRUB.

Compiled into the Debian version of the shim binary is Debian's own Secure Boot CA certificate. Once shim takes control, it executes grubx64.efi (provided by the grub-efi-amd64-signed package). However, before allowing GRUB to run, shim verifies that grubx64.efi is signed with Debian’s embedded certificate.

Passing Execution to the Kernel

Once grubx64.efi is validated and running, the verification chain continues:

  1. Kernel Verification: GRUB loads the Linux kernel (vmlinuz), calling back into shim's verification protocol to ensure the kernel image is signed by Debian's CA key.
  2. Kernel Lockdown: When booted under Secure Boot, the Linux kernel automatically activates "lockdown" mode. This restricts access to kernel memory (such as blocking /dev/mem access, hibernation, and raw I/O operations) to prevent root users from bypassing Secure Boot protections from userspace.
  3. Module Verification: The kernel will only load kernel modules (.ko files) that carry a valid signature from Debian.

Handling Custom and Third-Party Drivers via MOK

Because Debian's keys only sign official Debian kernels and packages, out-of-tree drivers (such as proprietary NVIDIA drivers or VirtualBox host modules) will fail validation by default.

To resolve this, shim implements the Machine Owner Key (MOK) architecture:

  • shim provides an on-boot management interface called MokManager.
  • Users can generate their own local cryptographic key pair, sign third-party modules locally, and register the public key using the user-space utility mokutil.
  • Upon the next reboot, shim catches the pending enrollment request and asks the user for confirmation via physical console access.
  • Once accepted, the custom key is stored in non-volatile storage managed by shim, allowing locally signed modules and custom kernels to pass validation alongside official Debian software.