Secure Boot is a feature of UEFI firmware. Before the firmware runs a boot program, it checks that program's cryptographic signature against a set of keys stored on the motherboard. If the signature traces back to a key the firmware recognises, the program runs. If it does not, the firmware refuses and reports the refusal.
That is the whole mechanism. Everything else is consequence.
The problem it addresses
Code that runs before the operating system has extraordinary reach. It sees the machine at its most trusting: no drivers loaded, no security software running, nothing yet in a position to observe it. Software that installs itself into that window can persist through a reinstall and remain invisible to anything running afterwards, because it was there first.
Signature checking closes that window by making the firmware refuse unfamiliar loaders. It is a narrow defence, but the thing it defends is unusually valuable.
What lives in the key store
| Store | Contains | Effect |
|---|---|---|
| PK | Platform key | Controls who may change the other stores |
| KEK | Key exchange keys | Authorises updates to the signature databases |
| db | Allowed signatures | Loaders matching these are permitted to run |
| dbx | Revoked signatures | Loaders matching these are refused, even if otherwise valid |
The revocation list matters more than it looks. When a signed loader is later found to contain a flaw that lets it start unsigned code, the fix is to add it to dbx. That is why firmware updates occasionally cause a previously working recovery drive to stop starting: the loader on it was withdrawn.
How open-source systems participate
Most Linux distributions solve the signing problem with a small first-stage loader, commonly called a shim, that is signed by a widely trusted authority. The shim carries the distribution's own key inside it and uses that key to verify the real loader that follows. The chain continues from there to the kernel and, on many systems, to kernel modules.
The practical upshot is that mainstream distributions start normally on a machine with signature checking enabled, and specialised or self-built images often do not.
What it does not do
A signature says who published a file and that it has not been altered since. It says nothing about whether the file is well written, whether it contains flaws, or whether the publisher's intentions were good. Signature checking is an identity control, not a quality control.
Its scope is also narrower than people often assume. The check covers the early boot chain. Once the operating system is running, protection comes from the operating system's own mechanisms, not from firmware. And because implementation is left to board vendors, the exact behaviour, menu wording and update path differ from one manufacturer to the next.
Living with it when you carry bootable media
The comfortable position is to keep the check enabled and to carry images that work with it. Mainstream distribution images generally do, and their release notes say so plainly. When you are choosing what to keep on a drive that has to work on machines you do not control — a client's laptop, a lab desktop, a friend's computer — compatibility with signature checking is a genuinely useful selection criterion, because you may not have the access or the standing to change firmware settings on someone else's machine.
Firmware setup on most boards does expose the setting, and vendors document where it sits. If you change it on a machine you own, note two things: some systems require you to set a firmware password before the option becomes editable, and turning the check back on later may require clearing and restoring the key store from the firmware's own defaults. Neither is difficult, but both are easier to do deliberately than to discover at an awkward moment.
When something is refused
- Read the message. Firmware usually distinguishes between "no bootable device" and "signature verification failed", and those point in different directions.
- Check whether the image publisher supports signature checking for that release. Many state it explicitly.
- Check whether a recent firmware update revoked an older loader you were relying on, and whether a newer image is available.
- Verify the image's checksum against the publisher's figure. A truncated download can present as a verification failure.