UEFI Secure Boot is a firmware-level mechanism that ensures each binary executed during the boot process — bootloader, kernel, UEFI drivers — is cryptographically signed by a key the firmware trusts, before it is allowed to run. It is defined in the UEFI specification and implemented by the firmware on virtually all modern x86 and ARM platforms. Its threat model is bootkits and rootkits that install themselves before the OS loads and therefore survive reboots, OS reinstalls, and cannot be detected by any software running after them.
Trust is managed through a four-level key hierarchy stored in authenticated UEFI variables. The Platform Key (PK) — enrolled by the OEM or system owner — is the root of trust; its private key is required to authorize any changes to the next layer. The Key Exchange Key (KEK) database holds keys authorized to update the signature databases. The signature database (db) lists the public keys and binary hashes that are trusted to execute at boot time. The revocation database (dbx) lists keys and hashes that are explicitly blocked, and always takes precedence over db — a binary matching a dbx entry is refused regardless of any db entry. At boot, firmware verifies each EFI binary’s signature against db (and checks it against dbx) before executing it; any failure halts the chain. The entire Secure Boot configuration — PK, KEK, db, dbx — is measured into TPM PCR 7, making the Secure Boot state part of the platform’s attestable identity. In day-to-day operation, firmware decides whether a binary may run by checking db and dbx only; most administrators never change PK, which is typically enrolled once by the OEM or platform owner and left in place for the life of the machine. PK and KEK become relevant when you take ownership of the trust store: enrolling your own keys into firmware, rotating or replacing signature databases, or running enterprise key management and custom Secure Boot policies (for example, restricting which signers may appear in db). For attestation and disk sealing, the full PK/KEK/db/dbx state still matters because it is what TPM PCR 7 records.
On Linux, distributions do not hold a key in the firmware’s db directly. Instead they rely on shim: a small Microsoft-signed EFI binary that acts as a second-stage trust anchor. Shim embeds the distribution’s own CA certificate and validates GRUB and the kernel against it, extending the chain of trust without requiring firmware modification. Shim also maintains a Machine Owner Key (MOK) database — a user-managed secondary trust store stored outside the UEFI variable hierarchy — that allows sysadmins to enroll their own signing keys (for custom kernels or out-of-tree modules) using mokutil, with changes only confirmable from the physical console at boot to prevent userland malware from silently enrolling keys. Secure Boot is a prerequisite for UKI-based measured boot: a UKI’s value as a single signed payload depends entirely on the firmware’s willingness to reject anything not carrying a valid signature.
Secure Boot does not, by itself, restrict what the running kernel may do after boot. Many Linux distributions therefore enable kernel lockdown when Secure Boot is active — typically integrity mode — which blocks or limits actions that could undermine boot-time guarantees, such as loading unsigned kernel modules, abusing sensitive interfaces, or using certain debugging features from privileged context. Lockdown is a runtime complement to firmware verification: Secure Boot attests what was loaded; lockdown reduces the chance that a compromised or malicious root can weaken the system in ways that matter for integrity-focused threat models. It is not a substitute for signed boot artifacts and does not replace measured boot or IMA where those are required.