Below the operating system lies a second stack: firmware (UEFI/BIOS), the bootloader, and the silicon that controls what software can run. The OS assumes integrity of these layers — an attacker who reaches firmware reaches everywhere, because firmware sees every byte the OS loads. This topic covers the hardware root of trust that makes the boot chain verifiable, and the side-channel attacks that bypass software entirely.

Outside the main path of an application engineer’s work, this matters as the upper bound of what an attacker can do — and the basis for several high-profile supply-chain attacks where the compromise lived below the OS.

The Boot Chain

The boot is a sequence: each stage verifies the next stage before executing it. The chain anchors in a small piece of trusted silicon — the root of trust — that the rest of the chain builds on.

  ROM (immutable, factory-burned)  ← root of trust
    ↓ verifies signature
  UEFI firmware (flashable but signed)
    ↓ verifies signature
  Bootloader (shim, GRUB)
    ↓ verifies signature
  Kernel image
    ↓ verifies signature
  Initramfs → userspace

Each arrow is a signature check: the verifying stage holds the public key of the signed next stage. The root of trust is the only thing that has to be implicitly trusted — usually store in ROM (or in an isolated TPM-like co-processor) so an attacker with flash-write access cannot substitute it.

A break anywhere in the chain — an unsigned payload the chain will execute — is a permanent backdoor. The lineage of firmware attacks (Equation Group, LoJax, Mosquito) all work at this level because they survive OS reinstalls.

Secure Boot vs Measured Boot

Two complementary processes run during boot. They are regularly conflated but address different risks:

Secure Boot: each stage cryptographically verifies the next; unverified code refuses to run. The defense property is enforcement — bad code does not execute.

Measured Boot: each stage SHA-256s the next stage’s image into the TPM’s Platform Configuration Registers (PCRs), an append-only hash chain. The defense property is attestation — even if bad code runs, the system has an irreversible record of what ran, verifiable by an external auditor.

Both are needed: Secure Boot blocks the easy attacks; Measured Boot catches the subtle ones where Secure Boot was somehow bypassed (e.g., a misconfigured trust list).

TPM 2.0 — What It Holds

The Trusted Platform Module is a discrete co-processor (or a TEE on modern SoCs) storing cryptographic secrets that the host OS cannot extract. The primitives:

• Platform Configuration Registers (PCRs) — append-only hash chain. PCR-7 records Secure Boot state; PCR-0 records firmware. To “extend PCR-X with value v”, the TPM computes PCR_X = SHA256(PCR_X || v) — not store v. The result is tamper-evident: only the same sequence of writes produces the same final PCR value.
• Sealing — encrypt key K to specific PCR values. The key unseals only during a boot that produced those PCR values; a different boot (different firmware, different kernel) cannot unseal.
• Attestation — a TPM-signed quote of “the PCRs at this moment” is a proof of remote software state. The verifier compares the quote to a known-good reference.
• Endorsement Key (EK) — TPM’s permanent private key (factory-installed) used to certify that a quote came from a real TPM. The EK’s presence is the trust anchor.

Production pattern: full-disk encryption keys sealed to PCR-7 — the disk key unseals at boot only if Secure Boot verified the kernel. An attacker who boots a different OS (say, an offline Linux USB to read the disk) cannot unseal the key.

Side-Channel Attacks

A side-channel attack recovers a secret by observing the system’s physical side-effects — execution time, memory access pattern, power consumption — rather than by breaking the cryptographic algorithm. Three families matter for the platform engineer:

The Meltdown / Spectre family (2017-) are the most consequential: they break the user/kernel boundary in speculative execution, a class of bug the CPU itself exhibits. Patches mitigate specific instances but the speculative-execution model leaves future variants discoverable. The defense against unknown-future side-channels is defence-in-depth — secrets never sitting in non-isolated memory or are rotated frequently.

Trusted Execution Environments

A TEE is an isolated execution enclave within the same CPU that holds code and data the OS cannot inspect. The OS cannot read enclave memory, even with kernel privilege; the CPU enforces the boundary via hardware. Production TEEs:

TEEs address the insider-with-hypervisor problem: a cloud operator with hypervisor privilege cannot read confidential-VM state. The hardware guarantees attestation (the user knows what code ran inside the enclave) and confidentiality (data inside is not readable from outside, even from a kernel or hypervisor).

Hardware Roots of Trust

The hardware itself is the lowest layer of defence. Three roots matter:

• Immutable ROM — the boot ROM burned at the factory is the root that verifies firmware’s signature. Cannot be patched; placing trust in the vendor’s QA here is unavoidable.
• TPM — discrete module that holds secrets the OS cannot directly read; used for measured boot and sealing.
• HSM (Hardware Security Module) — higher-assurance device for production key custody (PCIe card or network-attached); tamper-resistant, often tamper-evident; holds root-of-CA keys at the certificate authority, root-of-KMS keys at the cloud provider.

A typical strong defence: secure boot + measured boot + disk key sealed to TPM PCR-7 + cloud provider’s HSM for the top-of-tree KMS key + confidential VMs for the workloads the cloud operator must not see. Each layer fails independently; the attacker must compromise every layer.

Practice Trajectory

1. On a Linux host, check Secure Boot state (mokutil --sb-state). Examine PCR values via tpm2_pcrread. Identify which PCRs change after a kernel update.
2. Audit an existing disk-encryption setup. Identify which PCR state the disk key is sealed to; argue what would prevent unsealing on a modified kernel.
3. Pick a workload that processes sensitive data in the cloud. Evaluate the threat model of “the cloud operator can read the memory”. Describe what confidential computing (SEV-SNP / Nitro Enclaves) buys and what it doesn’t (the OS inside the guest can still be exploited).
4. Audit your crypto library: are the AES and comparison primitives using constant-time implementations? Identify any data-dependent branches in code that handles secrets.
5. Sketch the boot-chain trust anchors for a fleet of customer-premise devices (edge compute). Identify which anchors are controlled by you, which by the silicon vendor, and which by the firmware vendor.

When It’s the Right Tool