Your fleet of Linux servers currently boots with UEFI Secure Boot disabled. What does Secure Boot actually verify during the boot chain, and how would you decide whether to enforce it?

## What is actually being checked Secure Boot is a UEFI feature, so it applies only to native UEFI boot. The firmware holds several variables in NVRAM: a platform key that controls who may change the configuration, a key-exchange layer, an **allowed** signature database, and a **revocation** database. Before loading any EFI application, the firmware checks its signature against the allowed database and refuses anything present in the revocation list. That alone would be awkward for Linux, because the keys shipped by hardware vendors are not the distributions' keys. The standard arrangement is a small first-stage loader — commonly called a shim — signed by an authority whose key virtually all firmware already trusts. Firmware verifies the shim; the shim carries the distribution's key and verifies the bootloader; the bootloader and shim together verify the kernel. Administrators can also enrol their own key on a machine, which is what you need if you build your own kernels or sign your own modules; enrolment is deliberately interactive at the console, so it cannot be done silently by software. The chain therefore ends at the kernel. Everything after that — the initramfs on most distributions, the root filesystem, every binary you run — is **not** covered. If your mental model is "Secure Boot means only trusted code runs", it is wrong in a way that matters when you are deciding what it buys you. ## The second effect: lockdown On current distributions, booting with Secure Boot active also puts the kernel into a lockdown mode, on the reasoning that a verified kernel is pointless if root can rewrite it in memory. Lockdown closes the interfaces that would allow that: unsigned module loading, raw physical-memory access, loading an unverified image for kexec, and several debugging paths. This is where the operational cost usually shows up, because it turns a security posture into a compatibility constraint on out-of-tree drivers and on tooling that pokes at the running kernel. ## What it defends against, honestly The threat is **persistence before the operating system runs**. Code that installs itself in the bootloader or as a malicious kernel image executes before any defence you deploy inside Linux, and survives reinstalling the OS. Secure Boot makes that specific attack much harder. It is a meaningful control for laptops, for machines in locations you do not control, for colocation, and for anything where hardware passes through hands you do not own. It is a much weaker argument for a server in a cage you control, where an attacker with the physical access needed to tamper with the boot chain has cheaper options. And it does nothing about the compromise most organisations actually suffer: an application vulnerability leading to code execution as a service account. Naming that plainly is the difference between a security decision and a checkbox. ## What it is not Secure Boot **gates** what may load. It does not **record** what loaded — that is measured boot, where each stage hashes the next into a TPM's registers, letting a remote party attest to what the machine actually ran. If your goal is proving a machine's state to something else (releasing a disk key, admitting a node to a cluster), measurement and attestation are the mechanism, and Secure Boot is at best an input. Verifying the root filesystem's contents is a third, separate mechanism again. ## Making the decision Frame it as four questions. **Threat model.** Do machines pass through untrusted hands, or sit somewhere you cannot physically control? Do you have a compliance requirement that names it? If neither, be honest that this is defence in depth rather than a fix for a live risk. **Operational cost.** Which out-of-tree drivers do you depend on, and can you sign them? Do you build custom kernels? Does any tooling need the interfaces lockdown closes? Does your recovery process — booting rescue media, kexec-based fast reboot — still work when signatures are enforced? **Enrolment reachability.** Enrolling your own key is a console operation. Across hundreds of machines that means out-of-band management, and it means your provisioning path must produce signed artefacts from day one, not as a retrofit. **Revocation risk.** The revocation database exists because real boot-chain vulnerabilities get found, and firmware updates distribute those revocations. A revocation for a bootloader you are still running turns a fleet into unbootable hardware, at a time you did not choose. Enforcing Secure Boot means owning that update path deliberately. ## The shape of a good answer Enforce it where the threat is real and the cost is bounded — laptops and edge or colocated machines first, with a supported distribution kernel and no unsigned drivers — while treating the fleet's build, provisioning and recovery paths as the actual project. Do not enforce it as a blanket policy on a heterogeneous estate whose recovery story has not been tested against it, and do not let it substitute for the runtime controls that address the compromises you actually see.