secure boot
Suppose you build the most secure house in the world — but every night while you sleep, someone could swap your front-door lock for a fake one that lets them in. All your daytime security would be undone before you even wake. A computer faces this at startup: if an attacker can tamper with the very first code that runs when you power on, every defense loaded afterward is built on a lie. Secure boot is the mechanism that checks, at each step of starting up, that the next piece of software is genuine and unmodified before handing control to it.
It works as a chain of trust, each link verifying the next. When the machine powers on, the firmware (UEFI) begins with a small, trusted root and a set of cryptographic keys baked in by the manufacturer. Before it runs the bootloader, it checks the bootloader's digital signature against those trusted keys — if the signature is valid, the bootloader was produced by a trusted party and has not been altered, so it is allowed to run; if not, boot stops. The bootloader in turn verifies the operating-system kernel's signature before launching it, and the kernel can verify drivers and modules before loading them. So trust extends outward link by link from a hardware-protected root, and code that has been tampered with — say a rootkit that infected the bootloader — fails its signature check and is refused. A related idea, measured boot, does not block untrusted code but records a cryptographic measurement (a hash) of each stage into a tamper-resistant chip (a TPM), so the system can later prove exactly what software it booted.
Secure boot matters because it closes off one of the deepest attacks there is: malware that loads before the operating system and therefore before any antivirus or kernel defense exists, where it can hide perfectly and subvert everything above it (a so-called bootkit). By establishing trust from the very first instruction, secure boot makes the trusted computing base meaningful from power-on. The honest caveats are real, though. Secure boot guarantees that the code is signed by a trusted key — it does not guarantee the code is bug-free or even benign, only that it came from someone holding a trusted key, so a signed-but-vulnerable bootloader is still a hole. Who controls the keys is a genuine concern, since it touches the user's ability to run their own software (for instance, alternative operating systems). And secure boot protects the startup chain; it does nothing about attacks that strike after the system is up and running.
A bootkit rewrites the bootloader to load before the OS and hide itself. On next power-on, UEFI checks the bootloader's signature against the manufacturer's trusted keys; the tampered bootloader no longer matches a valid signature, so the firmware refuses to run it and halts (or falls back to a recovery image). The infection never gets to load.
Each stage verifies the next's signature before handing over control.
Secure boot proves code is signed by a trusted key — not that it is bug-free or even benign. A signed-but-vulnerable bootloader is still a hole, and it protects only the startup chain, doing nothing about attacks once the system is running.