Secure Boot: Establishing Trust from Power-On

A chain is only as strong as its weakest link. In boot security, this isn't a metaphor—it's an engineering constraint that shapes every design decision. If any single stage of the boot process fails to properly verify the next, the entire security model collapses.

Boot chain verification is the systematic process of ensuring that each component loaded during boot is authentic and unmodified before it executes. This verification begins with hardware-rooted trust and extends through firmware, bootloaders, the operating system kernel, and ultimately to early user-space components. Each stage acts as a gatekeeper for the next, collectively creating an unbroken chain from the Root of Trust to the running system.

Before examining each stage in detail, let's establish a complete view of the modern boot chain on a UEFI-based x86_64 system. This chain represents the sequence of trust transfers that must all succeed for a fully verified boot.

Chain Verification Properties

Each link in this chain must satisfy several properties:

1. Cryptographic Binding: The verification uses cryptographic hashes and/or signatures that make forgery computationally infeasible.

2. Temporal Ordering: Each verification happens BEFORE the verified component executes. There's no retroactive verification.

3. Unidirectional Trust: Trust flows in one direction—from hardware to software, from earlier stages to later stages. Later stages cannot modify earlier verification decisions.

4. Complete Coverage: Every piece of executable code is verified. Any unverified code represents a potential bypass.

5. Fail-Closed: Verification failure halts the boot process or enters recovery. Systems don't 'fall back' to unverified boot.

The hardware verification stage is the foundation upon which all other verification rests. This is where the immutable Root of Trust verifies the first mutable code—the platform firmware.

Once hardware verification bootstraps trust, firmware takes over the verification responsibility. Modern UEFI firmware is modular, with multiple phases and dozens of individual components—each requiring verification.

Firmware Volume Architecture

UEFI firmware is organized into Firmware Volumes (FVs)—logical containers that hold firmware files. Each FV can contain:

• PEI Modules (PEIMs): Pre-EFI Initialization modules
• DXE Drivers: Driver Execution Environment drivers
• Applications: Utilities, shell, diagnostic tools
• Data Files: Configuration, logos, option ROM images

SPI Flash Layout (Simplified)
┌────────────────────────────────────────────────────────┐
│ Descriptor Region (Flash regions, permissions)         │
├────────────────────────────────────────────────────────┤
│ Intel ME / AMD PSP Region (Separate processor FW)     │
├────────────────────────────────────────────────────────┤
│ BIOS Region                                            │
│  ┌─────────────────────────────────────────────────┐  │
│  │ FV_RECOVERY (SEC + PEI Core + Critical PEIMs)   │  │
│  ├─────────────────────────────────────────────────┤  │
│  │ FV_MAIN (DXE Core + DXE Drivers)                │  │
│  ├─────────────────────────────────────────────────┤  │
│  │ FV_LOGO (Boot graphics)                         │  │
│  ├─────────────────────────────────────────────────┤  │
│  │ NVRAM (UEFI Variables - PK, KEK, db, dbx, etc.) │  │
│  └─────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────┘

FV and FFS Verification

The Firmware File System (FFS) within each FV supports signed firmware files:

UEFI PI Specification Signing:

• Individual firmware files can be signed
• FV header contains hash of entire volume contents
• Nested verification: Volume hash verified first, then individual files

Verification Flow within Firmware:

1. Boot Guard verifies FV_RECOVERY (IBB)
   │
   ▼
2. SEC (Security Phase) executes from verified IBB
   │  - Establishes temporary memory (CAR)
   │  - Locates PEI Core within FV_RECOVERY
   │  - PEI Core is within already-verified region
   │
   ▼
3. PEI Core loads PEIMs from FV_RECOVERY
   │  - Each PEIM can have individual signature
   │  - Or: Entire FV hash was verified by Boot Guard
   │  - Memory Reference Code (MRC) PEIM initializes DRAM
   │
   ▼
4. PEI Core locates and verifies FV_MAIN
   │  - Uses hash/signature from verified FV_RECOVERY
   │  - Establishes trust before loading DXE Core
   │
   ▼
5. DXE Core loads DXE Drivers
   │  - Each driver verified individually (signature or hash)
   │  - Drivers published to UEFI protocol database
   │  - Secure Boot policy becomes active
   │
   ▼
6. BDS Phase loads OS bootloader
   - Bootloader verified via Secure Boot (db/dbx)

Option ROM Verification

Expansion cards (graphics, network, storage controllers) often contain Option ROMs—firmware that executes during boot to initialize the device. These present a verification challenge:

The Problem:

• Option ROMs execute during DXE phase
• They may be unsigned or signed by unknown vendors
• They have full DXE privilege—can modify memory, chain into boot
• Historically, a major attack vector

Solutions:

1. UEFI Secure Boot for Option ROMs: Starting with UEFI 2.3.1, Option ROMs can be verified just like bootloaders. Unsigned Option ROMs are blocked if Secure Boot is enabled.

2. Option ROM Deny Lists: Some firmware allows specifying which PCI devices' Option ROMs to block.

3. Centralized Option ROM Storage: Some enterprise systems store Option ROMs in the main firmware image rather than on the card, enabling pre-verification.

4. Hardware Validation: PCIe 5.0+ introduces IDE (Integrity and Data Encryption) for enhanced device authentication.

Practical Implications: On systems with Secure Boot enabled, inserting a PCIe card with an unsigned Option ROM may:

• Cause the card to not initialize (Option ROM blocked)
• Display a security warning
• In some configurations, halt boot entirely

This is a security feature, not a bug—it prevents malicious devices from executing arbitrary code during boot.

The bootloader is the bridge between firmware and the operating system. Its verification is typically performed by UEFI Secure Boot, but the bootloader itself must then verify the kernel and initramfs it loads.

GRUB and Kernel Lockdown

When booting with Secure Boot, the Linux kernel enables 'lockdown' mode, which restricts operations that could undermine boot security:

Lockdown Restrictions (Integrity Mode):

• Module signature enforcement
• Hibernation (could be used to inject code) restrictions
• kexec restrictions (loading alternate kernels)
• Direct hardware access restrictions
• /dev/mem access restrictions

Lockdown Restrictions (Confidentiality Mode):

• All integrity restrictions plus:
• Prohibit reading kernel memory
• Restrict BPF and performance monitoring
• Prevent kernel image extraction

These restrictions ensure that even with root access, an attacker cannot use the running kernel to bypass boot-time verification for the next boot.

Once the kernel is running, verification continues. Kernel modules are the extension code of the kernel, and unsigned modules represent a critical attack surface. Modern kernels enforce module signature verification when Secure Boot is active.

Linux Kernel Module Signing Facility

The Linux kernel includes a cryptographic module signature verification system:

Configuration Options:

CONFIG_MODULE_SIG=y          # Enable signature verification
CONFIG_MODULE_SIG_FORCE=y    # Reject unsigned modules
CONFIG_MODULE_SIG_ALL=y      # Sign all modules during build
CONFIG_MODULE_SIG_SHA256=y   # Use SHA-256 for hashing
CONFIG_MODULE_SIG_KEY="..." # Path to signing key

Signature Format: Module signatures are appended to the module file. The signature structure includes:

• Algorithm ID (hash + encryption algorithm)
• Key ID (fingerprint of signing key)
• Signature data (PKCS#7 format)
• Magic number for detection

Verification Flow:

1. modprobe/insmod requests module load
   │
   ▼
2. Kernel reads module from filesystem
   │
   ▼
3. Kernel checks for signature appended to module
   │  If no signature and CONFIG_MODULE_SIG_FORCE: REJECT
   │
   ▼
4. Kernel verifies signature against trusted keys
   │  Trusted keys: Embedded in kernel + secondary keyring
   │  If verification fails: REJECT
   │
   ▼
5. Module loaded into kernel memory
   │
   ▼
6. Module init function executed

Kernel Keyring Architecture

The kernel maintains multiple keyrings for trusting module signatures:

Built-in Keyring (.builtin_trusted_keys)

• Keys embedded in the kernel binary at compile time
• Includes the kernel's own signing key
• Cannot be modified at runtime
• Primary source of trust for distro-signed modules

Secondary Keyring (.secondary_trusted_keys)

• Can be populated at runtime (with restrictions)
• Keys must chain to a key in the built-in keyring
• OR: Keys can be added by root if SYSTEM_BLACKLIST_HASH_LIST allows

Platform Keyring (.platform)

• Keys from UEFI Secure Boot db variable
• Automatically populated from db during boot
• Allows modules signed by db-trusted certificates

Machine Keyring (.machine)

• Keys from Machine Owner Key (MOK)
• Populated from shim's MOK variables
• Allows locally-enrolled certificate to sign modules

This layered keyring system enables:

• Distribution-signed modules (built-in keys)
• Shim-registered custom keys (MOK → machine keyring)
• Enterprise keys (via platform keyring)
• All while maintaining the chain of trust

When one boot stage transfers control to the next, it must pass the verification context properly. The handoff mechanism differs between stages and has significant security implications.

Shim → GRUB Handoff in Detail

The shim-to-GRUB handoff is particularly interesting because shim must provide GRUB with the ability to verify the kernel:

Shim Lock Protocol: Shim publishes a "shim lock protocol" that GRUB (and any other shim-loaded binary) can use:

// Shim Lock Protocol Interface
typedef struct {
    EFI_STATUS (*Verify)(void *buffer, UINT32 size);
    EFI_STATUS (*Hash)(void *data, UINT32 datasize, 
                       void *hash, UINT32 hashsize);
    EFI_STATUS (*Context)(void *buffer, UINT32 size, 
                          void **context);
} SHIM_LOCK;

GRUB Verification via Shim:

1. GRUB locates the SHIM_LOCK protocol
2. Before loading kernel, GRUB calls Verify(kernel_buffer, size)
3. Shim checks MOK + embedded certificate + UEFI db
4. If verification passes, shim returns EFI_SUCCESS
5. GRUB proceeds to load the kernel
6. If verification fails, GRUB refuses to load

This design means GRUB doesn't need to implement its own verification logic or have access to signing keys—it delegates to shim, which has the complete trust context.

Bootloader → Kernel Handoff in Detail

This transition is critical because the kernel must trust configuration data from the bootloader:

Information Passed to Linux Kernel:

• Boot parameters (cmdline): Kernel command line (root device, init, etc.)
• Memory map: E820 or UEFI memory map
• initramfs location and size: Pointer to initial ramdisk in memory
• ACPI tables pointer: Hardware description
• UEFI system table: Access to runtime services, variables

Security Concern: Command Line Manipulation

The kernel command line can fundamentally alter system behavior:

• init=/bin/sh → Boot to root shell
• selinux=0 → Disable SELinux
• module.sig_enforce=0 → Disable module signing

If an attacker controls the bootloader, they can pass arbitrary parameters. Secure Boot mitigates this by ensuring only signed bootloaders (which have whitelisted parameters or lock parameters) execute.

Unified Kernel Images (UKI) Solution:

UKIs bundle cmdline into the signed binary, preventing parameter manipulation:

┌─────────────────────────────────────┐
│ Unified Kernel Image (PE binary)   │
│ ┌─────────────────────────────────┐ │
│ │ EFI stub                        │ │
│ ├─────────────────────────────────┤ │
│ │ Kernel image                    │ │
│ ├─────────────────────────────────┤ │
│ │ initramfs                       │ │
│ ├─────────────────────────────────┤ │
│ │ Kernel cmdline (fixed)          │ │  ← Signed with everything
│ ├─────────────────────────────────┤ │
│ │ Signature                       │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────┘

With UKI, there's no separate cmdline to manipulate—it's cryptographically bound to the kernel.

When verification fails at any point in the boot chain, the system must respond appropriately. The response varies by stage and has significant implications for both security and usability.

Diagnosing Verification Failures

When boot fails with Secure Boot, systematic diagnosis is essential:

Step 1: Identify the failing stage

• No display at all → Hardware/Boot Guard level
• Firmware error screen → UEFI Secure Boot rejected bootloader
• Shim error screen → Shim rejected secondary bootloader or kernel
• GRUB error → GRUB rejected kernel
• Boot proceeds but modules fail → Kernel module signature issue

Step 2: Determine the specific failure

• Is the image unsigned? (Most common)
• Is the signing key not enrolled?
• Has the image/key been revoked (in dbx)?
• Is there a signature format mismatch?

Step 3: Check databases and signatures

# View current db/dbx/KEK
efi-readvar -v db
efi-readvar -v dbx

# View MOK
mokutil --list-enrolled

# Check an image's signature
sbverify --list /boot/efi/EFI/ubuntu/shimx64.efi

# Check if an image's hash is in dbx
pesign --signature-at 0 -i /path/to/binary --show-signature
# Compare signer hash against dbx entries

Step 4: Resolve

• If unsigned: Sign the image
• If key not enrolled: Enroll key (MOK or db)
• If revoked: Update to non-revoked version
• If format issue: Re-sign with correct format/algorithm

Boot chain verification is the systematic propagation of trust from an immutable root through every component that executes before the system is fully operational. Let's consolidate the essential insights:

What's Next:

With a comprehensive understanding of boot chain verification, we'll now explore TPM (Trusted Platform Module)—the hardware component that doesn't just verify boot but measures and records it. TPM enables remote attestation, sealed secrets, and a cryptographic log of exactly what booted, providing verifiability beyond the boot moment.