How Heads Protects the Boot Process with coreboot and the TPM

Updated

Heads protects the boot process by moving the root of trust into the write-protected region of the SPI flash, measuring each boot firmware and configuration step into the TPM so the machine can be attested locally or remotely, and then using the TPM as hardware key storage to decrypt the drive once the system is in a known good state. It applies to laptops and servers where data and state must persist on the machine — the opposite of a stateless OS like Tails. The protection is meaningful but not absolute: it raises the cost of several classes of boot and physical attacks rather than securing against every possible vector.

What Heads actually is

Heads is an open source custom firmware and OS configuration for laptops and servers. It is not another Linux distribution. It combines:

  • Physical hardening of specific hardware platforms
  • Flash security features
  • Custom coreboot firmware
  • A Linux boot loader stored in ROM

On platforms that support it, Bootguard enforces verified boot of the firmware. Controlling the first instruction the CPU executes is what makes the rest of the measurement chain possible.

The trust chain, step by step

1. Root of trust in write-protected flash

The root of trust lives in the write-protected region of the SPI flash. This prevents further software modifications to the bootup code. Because the first instruction is fixed, everything downstream can be measured reliably.

2. Measurement into the TPM

Controlling the first instruction lets Heads measure every step of the boot firmware and configuration into the TPM. This produces evidence that the machine has not been tampered with, which can be presented to the user or to a remote system (attestation).

One caveat Heads documents openly: modern Intel CPUs require binary blobs to boot. These non-Free components are included in the measurements, so they are at least guaranteed to be unchanging — you can detect modification even though you cannot audit the blob.

3. TPM as hardware key storage

Once the system reaches a known good state, the TPM is used as hardware key storage to decrypt the drive. Decryption is therefore tied to the measured boot state rather than to a password alone.

4. User-signed hypervisor, kernel, and initrd

The hypervisor, kernel, and initrd images are signed by keys the user controls. Firmware-level trust does not extend to unsigned boot content.

What this defends against

Trammel Hudson's 2016 33C3 presentation introducing Heads catalogues specific attack classes and mitigations. One example given is Thunderstrike — DMA over Thunderbolt rewriting SPI flash — countered by enabling IOMMU/VT-d and by coreboot disabling the relevant path. The general pattern: attacks on the boot process and on physical hardware that traditional installations neglect become substantially harder.

Limits and conditions to weigh

  • Hardware-specific. The physical hardening applies to specific supported platforms, not arbitrary machines.
  • Persistence-oriented. Heads assumes you store data and state on the computer. If your goal is leaving no trace, a stateless OS is the right tool instead.
  • Not comprehensive. The project itself frames the result as raising difficulty beyond what most attackers will spend, not as complete protection.
  • Ongoing maintenance is not free. Heads and its wiki are free and open source, but upkeep is ongoing work; the project asks for support via GitHub Sponsors (tlaurion) or Open Collective (Insurgo), with details on the Community page.

Practical takeaway

If you need a machine that stores data and you want verifiable boot integrity plus drive encryption bound to a measured state, Heads is designed for that case — provided your hardware is among the supported platforms and you accept user-managed signing keys as part of the workflow. If you need a stateless environment, Heads is the wrong fit by design.