Skip to content

Secure Boot

Technical Overview

Secure Boot is a UEFI security feature that verifies the cryptographic signature of each component in the boot chain before executing it. The goal is to ensure that only software trusted by the platform owner can run before the OS kernel, preventing bootkits and rootkits from establishing persistence at the firmware level.

The mechanism is straightforward in concept: each binary in the boot chain is signed with a private key, and the verifying entity holds the corresponding public certificate in a trusted database. If the signature does not match any trusted certificate, execution is refused. In practice, the certificate hierarchy, the role of the shim loader, and the distinction between platform owner and end user make the implementation considerably more complex.

Secure Boot does not prevent malware from running within the OS — it only guarantees the integrity of the path from firmware to kernel. Its value is in blocking persistent firmware-level compromises that survive OS reinstallation.

Prerequisites

  • UEFI boot process (see 02-uefi.md)
  • PKI fundamentals: X.509 certificates, RSA/ECDSA signatures, certificate chains
  • GRUB2 architecture (see 04-grub2.md for GRUB2 internals)
  • TPM concepts helpful for attestation section (see 08-tpm-and-measured-boot.md)

Historical Context

Microsoft introduced Secure Boot requirements for Windows 8 Logo certification in 2012. The requirement had two parts: UEFI firmware must support Secure Boot, and it must ship with Microsoft's certificate enrolled as a trusted key. This was technically sound but caused immediate controversy in the Linux community.

The concern: if OEMs only enrolled Microsoft's key, and if Microsoft chose not to sign Linux bootloaders, Linux would be unbootable on certified hardware. Microsoft addressed this by offering to sign bootloaders through their Authorized Signing Program, and by requiring that x86/x64 hardware provide a mechanism to disable Secure Boot or add custom keys (a requirement that does not apply to ARM Windows devices, which created a separate controversy).

The Fedora project developed the shim loader as a pragmatic solution: shim is a Microsoft-signed first-stage loader that establishes a secondary trust chain, allowing Linux distributions to manage their own signing without depending on Microsoft for every kernel update.

The ecosystem has since matured into an uncomfortable but workable arrangement: Microsoft's certificate is the root of trust on most x86 hardware, shim is the de facto standard, and distributions maintain their own signing infrastructure.

PKI Hierarchy

Secure Boot uses a four-level certificate hierarchy stored as UEFI authenticated variables:

Secure Boot PKI Hierarchy

  +-------------------------------------------+
  |  PK (Platform Key)                        |
  |  - Single X.509 certificate               |
  |  - Owned by OEM or enterprise admin       |
  |  - Signs KEK updates                      |
  |  - Presence enables Secure Boot           |
  |  - Absence = Setup Mode (no SB)           |
  +-------------------------------------------+
              |
              | signs
              v
  +-------------------------------------------+
  |  KEK (Key Exchange Key)                   |
  |  - One or more X.509 certificates         |
  |  - Typically: Microsoft KEK cert          |
  |               (for db/dbx updates)        |
  |  - Signs updates to db and dbx            |
  +-------------------------------------------+
              |
              | authorizes entries in
              v
  +-------------------------------------------+
  |  db (Signature Database)                  |
  |  - List of trusted certs or hashes        |
  |  - If signer cert is in db → allow        |
  |  - If binary hash is in db → allow        |
  |  Microsoft UEFI CA 2011 cert in db        |
  |  by default on most OEM hardware          |
  +-------------------------------------------+
  |  dbx (Forbidden Signature Database)       |
  |  - Revocation list                        |
  |  - Hashes of compromised binaries         |
  |  - Certs of revoked signers               |
  |  - Takes priority over db                 |
  +-------------------------------------------+

PK (Platform Key): Exactly one certificate. Proves the platform's identity. Writing to PK in Setup Mode (when no PK is enrolled) transitions the platform to User Mode, enabling Secure Boot enforcement. The PK is typically set by the OEM (Dell, HP, Lenovo) with their own certificate. Enterprise customers can replace the PK with their own to establish full control.

KEK (Key Exchange Key): Authorizes updates to the db and dbx. Microsoft requires OEMs to include their KEK certificate so Microsoft can push dbx revocations (e.g., to block compromised bootloaders) without requiring OEM involvement.

db: The positive trust list. An EFI application is allowed to execute if its signature was made by a certificate in db, or if its SHA-256 hash is in db. OEM db databases typically include: Microsoft Windows Production PCA certificate, and Microsoft UEFI CA certificate (which is used to sign the shim bootloader that Linux distributions use).

dbx: The negative trust list. Takes precedence over db. Binaries whose hashes or signing certs appear in dbx are blocked even if their signer is in db. The dbx is the mechanism by which compromised bootloaders are revoked globally.

Secure Boot Validation Flow

Secure Boot Chain of Trust

  UEFI Firmware (verified by PK hierarchy)
       |
       | loads and verifies signature against db
       v
  +------------------+
  | shimx64.efi      |  ← Microsoft-signed EFI app
  |                  |     (Microsoft UEFI CA in firmware db)
  | Embeds:          |
  |  - Vendor cert   |
  |    (e.g., Red Hat,|
  |     Canonical)   |
  |  - MOK list      |
  +--------+---------+
           |
           | verifies signature using embedded vendor cert
           | or MOK certificates
           v
  +------------------+
  | grubx64.efi      |  ← Signed by distro vendor
  |                  |
  | Verifies:        |
  |  - grub.cfg      |
  |    (GPG sig on   |
  |     Fedora SB)   |
  +--------+---------+
           |
           | loads and verifies
           v
  +------------------+
  | vmlinuz          |  ← Kernel image, signed by distro
  |                  |
  | Verifies:        |
  |  - kernel modules|
  |    (module .ko   |
  |     signing key) |
  +------------------+
           |
           v
  OS running with signed kernel

Each link in the chain must be verified before the next is loaded. If any verification fails, the chain breaks and the system refuses to boot (or, depending on firmware configuration, falls through to the next boot entry).

Shim Loader

The shim is a thin EFI application, signed by Microsoft's UEFI CA, that acts as a second-stage loader. Its purpose is to allow Linux distributions to maintain their own boot-time signing infrastructure without needing Microsoft to sign every kernel update.

Shim carries an embedded DER-encoded certificate (the distribution's signing certificate, e.g., Red Hat Secure Boot certificate). It verifies the GRUB binary against this embedded certificate before handing off. Shim also consults the MOK (Machine Owner Key) list for additional trusted certificates.

Shim provides a fallback: if a binary fails verification, shim can invoke MokManager.efi (also signed by Microsoft) to allow the user to manually enroll a certificate or hash.

Source: https://github.com/rhboot/shim

Key functions: - verify_image(): Verify PE/COFF signature against embedded cert + MOK list - start_image(): Load and execute the verified EFI application (GRUB) - MokManager: Interactive enrollment of Machine Owner Keys

MOK (Machine Owner Key)

MOK allows end users and administrators to add their own signing certificates to the Secure Boot trust chain, without modifying the firmware's db variable (which requires PK-authorized writes).

MOK Enrollment Process

  1. User generates key pair:
     openssl req -newkey rsa:4096 -nodes -keyout MOK.key \
       -new -x509 -sha256 -days 3650 -out MOK.crt

  2. Import certificate to MOK list:
     mokutil --import MOK.crt
     (prompts for enrollment password)

  3. Reboot → shim detects pending MOK enrollment
     → launches MokManager.efi
     → user confirms enrollment with password

  4. Certificate stored in MokListRT UEFI variable
     (in volatile RT space, not authenticated db)

  5. Shim verifies binaries against db ∪ MOK list

MOK is used for: - Custom kernel builds (out-of-tree modules, distribution kernels) - DKMS-built kernel modules (NVIDIA driver, VirtualBox kernel module) - Custom bootloaders or EFI tools

The command mokutil --list-enrolled shows the current MOK database. The command mokutil --sb-state shows whether Secure Boot is enabled.

Secure Boot Bypass History

CVE-2020-10713 — BootHole (GRUB2)

Discovered by Eclypsium in July 2020. A buffer overflow in GRUB2's grub.cfg parser (grub_parser_split_cmdline()) could be exploited by a local attacker with access to the ESP. An attacker could replace grub.cfg with a crafted config that triggered the overflow, gaining code execution within the signed GRUB binary — bypassing Secure Boot because GRUB itself was legitimately signed.

Impact: Full Secure Boot bypass. Attacker gains pre-OS execution with arbitrary code.

Mitigation: Required coordinated update across all distributions + UEFI dbx updates to revoke all existing signed GRUB binaries + signing of new GRUB versions + shim updates. One of the most complex vulnerability coordination events in open-source history (involved 8+ Linux distributions + Microsoft + UEFI Forum).

Lesson: Signing a binary is not sufficient — the binary itself must be secure. A vulnerability in a signed component breaks the entire chain.

BlackLotus (2023) — CVE-2022-21894 UEFI Bootkit

BlackLotus was the first publicly documented UEFI bootkit capable of bypassing Secure Boot on fully patched Windows 11 systems. It exploited CVE-2022-21894 (Baton Drop), a vulnerability in the Windows Boot Manager that allows bypassing Secure Boot's secure rollback prevention.

Mechanism: BlackLotus installed a vulnerable version of the Windows Boot Manager (bootmgfw.efi) that had not yet been added to the UEFI dbx revocation list. By exploiting the rollback to an older, vulnerable bootloader, it could load an unsigned GRUB/shim-equivalent and establish persistence in the ESP.

Impact: Persistent UEFI-level infection surviving OS reinstallation. Disabled kernel code integrity, BitLocker, and HVCI (Hypervisor-Protected Code Integrity).

Mitigation: Microsoft issued dbx updates, but deploying dbx revocations is slow (risks bricking dual-boot systems) and incomplete (many enterprise systems with old dbx databases remain vulnerable).

Other Notable Bypasses

  • ThinkPwn (2016): SMM vulnerability in Lenovo firmware allowing NVRAM writes from ring-0
  • LogoFAIL (2023): Image parsing vulnerabilities in UEFI firmware's bitmap/PNG parsers, triggered before Secure Boot verification runs
  • PKFail (2024): ~200 device models shipped with a test Platform Key from AMI's reference implementation, allowing anyone with knowledge of the private key to sign and execute arbitrary EFI applications

TPM Integration

Secure Boot and TPM integration creates a measured + verified boot chain:

Secure Boot + TPM Integration

  UEFI Firmware
    ├── Measures self into PCR[0]
    ├── Measures Secure Boot policy into PCR[7]
    │     (db, dbx, PK, KEK state)
    ├── Verifies shim signature (Secure Boot)
    ├── Measures shim into PCR[4]
    ├── Loads shim
  Shim
    ├── Measures GRUB into PCR[4] (via EFI app load)
    ├── Verifies GRUB signature
    ├── Loads GRUB
  GRUB
    ├── Measures kernel cmdline into PCR[8]
    ├── Measures initrd into PCR[9]
    ├── Loads kernel
  Kernel
    └── Passes PCR values to OS for attestation

TPM PCR[7] specifically records Secure Boot state (whether it was enabled, which keys are enrolled). This value becomes part of the TPM attestation quote that proves the boot configuration to a remote verifier.

See 08-tpm-and-measured-boot.md for full TPM details.

Secure Boot Attestation

Attestation is the process by which a system proves to a remote verifier that it booted into a known-good state. The components:

  1. Endorsement Key (EK): Unique asymmetric key pair burned into TPM at manufacture. Serves as the TPM's identity.
  2. Attestation Key (AK): Ephemeral key derived from EK for signing PCR quotes.
  3. PCR Quote: TPM signs current PCR values with AK, producing a cryptographically verifiable snapshot of boot state.
  4. Remote Verifier: Receives the quote + EK certificate, verifies that the PCRs match expected values for a known-good boot.

In cloud environments (Azure Attestation, AWS Nitro Attestation), this is used to verify that a VM booted with the expected firmware and OS image before releasing secrets (e.g., database credentials).

Enabling and Disabling Secure Boot

Linux systems:

# Check Secure Boot status
mokutil --sb-state
# or
[ -d /sys/firmware/efi ] && bootctl status | grep "Secure Boot"

# Disable Secure Boot (requires firmware setup access)
# Most systems: F2/F12/Delete during POST → Security tab → Secure Boot → Disabled

# Re-enable (may require clearing keys first on some firmware)
# Firmware setup → Security → Restore Secure Boot keys → Enable

Windows systems:

# Check Secure Boot status
Confirm-SecureBootUEFI

# msinfo32 → System Summary → Secure Boot State

Enterprise management:

# HP Moonshot / enterprise systems via iLO
hponcfg -r 0 -m 1 -c <xml_config_for_secure_boot_disable>

# Dell systems via racadm
racadm set BIOS.SysSecurity.SecureBoot Disabled

# Linux sbsigntools for signing EFI binaries with custom keys
sbsign --key MOK.key --cert MOK.crt \
  --output grubx64.efi.signed grubx64.efi

# Verify signature
sbverify --cert MOK.crt grubx64.efi.signed

Secure Boot in Virtualization

QEMU/KVM with OVMF supports Secure Boot for testing:

# OVMF with Secure Boot enabled
cp /usr/share/OVMF/OVMF_VARS.secboot.fd /tmp/vars.fd
qemu-system-x86_64 \
  -drive if=pflash,format=raw,readonly=on,\
    file=/usr/share/OVMF/OVMF_CODE.secboot.fd \
  -drive if=pflash,format=raw,file=/tmp/vars.fd \
  -machine type=q35,smm=on \
  -global driver=cfi.pflash01,property=secure,value=on \
  ...

Cloud VMs: AWS EC2 instances with uefi-preferred or tpm-v2.0 boot mode use UEFI with Secure Boot. Azure Trusted Launch VMs enforce Secure Boot + vTPM. GCP Shielded VMs combine Secure Boot, Measured Boot, and vTPM.

Debugging Notes

Secure Boot blocks valid kernel: After kernel update, if the new kernel binary is not yet signed, or if the signing certificate changed, boot will fail. Recovery: disable Secure Boot temporarily in firmware setup, boot, then enroll the new certificate via MOK.

shimx64.efi signature invalid: The shim binary's Microsoft signature may be in dbx (revoked). This happens after major security incidents. Recovery requires updating shim to a non-revoked version — typically handled by distribution updates, but if the system cannot boot to install updates, requires external boot media.

MOK not persisting: MOK is stored in authenticated UEFI variables. Some firmware implementations have bugs that cause MOK to not persist across reboots. Workaround: use mokutil --import again, or enroll the hash directly (mokutil --hash-file).

Secure Boot state mismatch: If PCR[7] does not match expected values during attestation, check that Secure Boot is actually enabled (mokutil --sb-state) and that the enrolled keys match expectations (efi-readvar -v db).

# List contents of Secure Boot databases
efi-readvar -v db     # trusted certificates
efi-readvar -v dbx    # revoked hashes/certs
efi-readvar -v KEK
efi-readvar -v PK

Security Implications

Threat model: Secure Boot defends against an attacker with physical access who replaces the bootloader on disk, or against OS-level malware that modifies the bootloader. It does not defend against: - Vulnerabilities in signed components (BootHole) - Compromise of signing keys - Firmware vulnerabilities (LogoFAIL, ThinkPwn) - Social engineering (user enrolling malicious MOK)

Key management is the hard problem: The security of the entire chain depends on the signing keys never being compromised. Distributions typically sign with an HSM (Hardware Security Module) in an air-gapped facility with multi-party authorization. Key compromise (or leakage of a test key, as in PKFail) invalidates the entire trust chain for affected hardware.

dbx update deployment lag: The revocation mechanism (dbx) is only effective if firmware contains the updated dbx. Many systems never receive dbx updates. Enterprise systems require active management (SCCM, Ansible, fwupd) to keep dbx current.

Performance Implications

Secure Boot signature verification adds measurable time to the boot process:

  • RSA-2048 verification: ~5ms on modern hardware
  • Full chain (shim → GRUB → kernel): 15–50ms total verification overhead
  • Module signature verification: Each .ko file verified at load time; systems loading 100+ modules add 1–5 seconds

This is negligible for servers but perceptible in embedded systems or systems with many DKMS modules.

Failure Modes

Complete boot failure after dbx update: A dbx update that revokes a currently-installed bootloader version without a simultaneous bootloader update will prevent the system from booting. Microsoft has shipped dbx updates that temporarily bricked dual-boot systems. Always test dbx updates on non-production systems first.

Lost PK with no recovery: If the PK is set to a certificate whose private key is lost, the only recovery is physical access to UEFI setup to put the system in Setup Mode (clear PK), re-enroll fresh keys. Some enterprise firmware requires a physical presence assertion (a jumper or IPMI command) to clear PK.

Shim bootloop: If shim verification fails but the UEFI fallback path \EFI\BOOT\BOOTX64.EFI points back to shim, the system enters a bootloop. Recovery requires either booting from external media or using the UEFI Shell to execute a different binary.

Modern Usage

Secure Boot is now the default on all new x86 hardware and increasingly on ARM:

  • Windows 11: Mandatory UEFI + Secure Boot. TPM 2.0 also required.
  • Android: Full verified boot chain (analogous to Secure Boot) using dm-verity + AVB (Android Verified Boot).
  • macOS: Apple Secure Boot on T2 and Apple Silicon Macs is more restrictive than UEFI Secure Boot — user cannot disable it (Reduced Security mode still verifies OS, Full Security verifies Apple signatures only).
  • Embedded Linux: Yocto and OpenEmbedded projects have reference implementations for Secure Boot in embedded scenarios.

Future Directions

  • UEFI Secure Boot with SBAT (Secure Boot Advanced Targeting): SBAT (introduced 2021) adds generation numbers to signed components, enabling efficient revocation without requiring hash-based dbx entries. Each signed binary includes an SBAT section with component name + generation. Revocation updates an SbatLevel UEFI variable rather than adding to dbx.

  • Kernel Lockdown: Linux kernel lockdown LSM (merged 5.4) restricts what a root user can do when Secure Boot is active — prevents /dev/mem writes, unsigned module loading, kexec to unsigned kernels.

  • UEFI Secure Boot for confidential VMs: Azure CVM + AWS Nitro uses Secure Boot as part of the attestation chain proving the VM is running unmodified code.

  • Post-quantum Secure Boot: Current Secure Boot uses RSA-2048/RSA-4096 or ECDSA-384. NIST PQC standards (CRYSTALS-Dilithium, FALCON) will need to be integrated into UEFI signing infrastructure as quantum computing threat matures.

Exercises

  1. Certificate Chain Inspection: On a Secure Boot-enabled Linux system, use efi-readvar -v db and openssl x509 -inform DER -text -noout to inspect the X.509 certificates in the db database. Identify the Microsoft UEFI CA certificate's subject, issuer, validity period, and key size.

  2. MOK Enrollment: Generate a 4096-bit RSA key pair with openssl. Sign a test EFI binary (use the UEFI Shell binary from an OVMF installation) with sbsign. Enroll the certificate via mokutil --import. Reboot and verify the enrollment with mokutil --list-enrolled. Test that the signed binary passes sbverify with the enrolled cert.

  3. BootHole Reproduction (safe lab): In a QEMU VM with OVMF and Secure Boot enabled, examine the GRUB2 binary version and confirm it predates or postdates the BootHole fix. Use strings on grubx64.efi to find the GRUB version string. Compare against known-vulnerable version ranges.

  4. dbx Inspection: Download the current UEFI dbx from https://uefi.org/revocationlistfile. Parse it with python-efitools or sig-list-to-certs. Identify the most recently added entries — what components were revoked and why?

  5. Attestation Simulation: On a system with TPM 2.0, use tpm2-tools to read PCR[7] (tpm2_pcrread sha256:7). Change the Secure Boot state (enable/disable in firmware). Reboot and re-read PCR[7]. Confirm that the PCR value changes, and explain why this is the basis for remote attestation.

References

  • UEFI Specification 2.10, Section 32 — Secure Boot: https://uefi.org/specifications
  • shim source and documentation: https://github.com/rhboot/shim
  • BootHole CVE-2020-10713 analysis: https://eclypsium.com/research/boothole/
  • BlackLotus ESET analysis: https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/
  • PKFail research (Binarly): https://binarly.io/posts/pkfail/
  • SBAT specification: https://github.com/rhboot/shim/blob/main/SBAT.md
  • mokutil man page and source: https://github.com/lcp/mokutil
  • Linux kernel security/lockdown/ — kernel lockdown LSM
  • "A Tour Beyond BIOS with the UEFI Secure Boot" — Vincent Zimmer (EDK2 documentation)
  • NIST IR 8320 — Hardware-Enabled Security for Server Platforms