Heads: the other side of TAILS

Heads is a configuration for laptops and servers that tries to bring more security to commodity hardware. Among its goals are:

• Use free software on the boot path
• Move the root of trust into hardware (or at least the ROM bootblock)
• Measure and attest to the state of the firmware
• Measure and verify all filesystems

NOTE: It is a work in progress and not yet ready for non-technical users. If you're interested in contributing, please get in touch. Installation requires disassembly of your laptop or server, external SPI flash programmers, possible risk of destruction and significant frustration.

More information is available in the 33C3 presentation of building "Slightly more secure systems".

Documentation

The doc/ directory contains technical reference documentation for the Heads codebase. Start here:

Document	What it covers
doc/architecture.md	Component overview, x86/ppc64 differences, and build-system layers
doc/build-artifacts.md	x86/ppc64 output layout, filename rules, and size/hash manifest semantics
doc/reproducible-builds.md	Variance-reduction practices and same-commit comparison workflow
doc/modules.md	Module selection, build stamps, rebuild helpers, and HCL dependencies
doc/security-model.md	Trust hierarchy, measured boot, TOTP/HOTP attestation, GPG boot signing, LUKS DUK, fail-closed design
doc/boot-process.md	Step-by-step boot flow: /init → gui-init → kexec-select-boot → OS handoff
doc/tpm.md	PCR assignments, sealing policies, SRTM chain, board-specific TPM variations, developer config reference
doc/ux-patterns.md	GUI/UX conventions: whiptail wrappers, integrity report, error flows
doc/config.md	Board and user configuration system
doc/docker.md	Pinned-image build and comparison workflow using Docker
doc/circleci.md	CircleCI pipeline layout, workspace flow, and cache behavior
doc/qemu.md	QEMU board targets for development and testing
doc/wp-notes.md	Flash write-protection status per board
doc/BOARDS_AND_TESTERS.md	Supported boards and their maintainers/testers
doc/prerequisites.md	USB security dongles (HOTP/TPMTOTP), OS requirements, flashing methods
doc/faq.md	Common questions: UEFI vs coreboot, TPM, LUKS, threat models
doc/keys.md	All keys and secrets: TPM owner, GPG PINs, Disk Recovery Key, LUKS DUK
doc/development.md	Commit conventions, coding standards, testing checklist
doc/build-freshness.md	Debugging stale builds: cpio composition, BCJ/XZ filters, verification
Hardware Compatibility — intended publication target	Not a working link: https://osresearch.net/Hardware-Compatibility/ currently returns 404. Per-board summaries and HCL anchors live in the board configs; the deployment status is recorded once, in doc/modules.md

For user-facing documentation and guides, see Heads-wiki.

Contributing

We welcome contributions to the Heads project! Before contributing, please read our Contributing Guidelines for information on how to get started, submit issues, and propose changes.

Building Heads

Heads builds inside a versioned Docker image. The supported and tested workflow uses the provided Docker wrappers — no host-side QEMU or swtpm installation is needed.

Clone the Repository

Clone with full history to ensure version tags are available for git describe --tags (used at build time for artifact filenames):

git clone https://github.com/linuxboot/heads.git
cd heads

To repair an existing shallow clone (--depth 1 was used) or if artifact filenames show a trailing _- (missing git abbreviation):

git fetch --unshallow origin
git fetch --tags origin

Quick start (requires Docker CE):

./docker_repro.sh make BOARD=EOL_x230-hotp-maximized
./docker_repro.sh make BOARD=qemu-coreboot-fbwhiptail-tpm2 run

From a non-interactive context (CI, agents, no TTY), docker_repro.sh's -ti still needs a pseudo-TTY: wrap the command in script. Pass -f so script flushes output as it is written instead of buffering it, and set HEADS_DISABLE_USB=1 to skip the USB token passthrough:

script -qefc "HEADS_DISABLE_USB=1 ./docker_repro.sh make BOARD=EOL_t480-hotp-maximized"

script (util-linux) allocates a pseudo-terminal (PTY) so docker run -ti has a TTY in a non-interactive/agent context; the command's output is still shown on screen (stdout). The options used above:

• -c "<cmd>" runs that command.
• -q suppresses script's own start/done banners.
• -e propagates the command's exit status, so a failed build is detectable.
• -f flushes output as it is written (no buffering), so incremental readers don't see it stall.

script also records the session to a file — by default ./typescript, which this repo gitignores (.gitignore:34 typescript*). Leave it default to keep the transcript; pass /dev/null as the trailing argument to skip recording.

HEADS_DISABLE_USB=1 skips USB-token passthrough and its 3-second abort window.

No hardware required for testing — Docker provides the full build stack and QEMU runtime with software TPM (swtpm) and the bundled canokey-qemu virtual OpenPGP smartcard. Build and test entirely in software before flashing real hardware.

Build targets are the directory names under boards/. For the current set of tested and maintained targets, see doc/BOARDS_AND_TESTERS.md. Outputs go under build/<arch>/<board>/: x86 boards use build/x86/, while UNTESTED_talos-2 uses build/ppc64/ and its Talos-specific .tgz layout. See architecture.md and build-artifacts.md.

For full details — wrapper scripts, Nix local dev, reproducibility verification, and maintainer workflow — see doc/docker.md.

For CI cache/workspace behavior and the CircleCI job graph, see doc/circleci.md.

For QEMU board testing see doc/qemu.md.

For troubleshooting build issues see doc/faq.md and doc/build-freshness.md.

General notes on reproducible builds

Heads applies reproducibility-oriented mechanisms: a selected GCC build, verified package inputs, pinned timestamps/build flags, normalized archive metadata, and a pinned Docker image on the canonical wrapper path. These reduce common sources of variation but do not make one build's output inherently bit-identical to another.

After the toolchain is available, the top-level Makefile downloads packages, verifies their hashes, applies Heads-specific patches, builds with the selected compiler, and stages the resulting files into the initrd. Establishing bit-identical ROM output requires comparable same-commit builds and an explicit artifact/hash comparison; see doc/reproducible-builds.md.

Key components

Heads builds a curated set of packages (from modules/). Key components enabled by most board configs include:

• musl-cross-make — cross-compiler toolchain
• coreboot — minimal firmware replacing vendor BIOS/UEFI
• Linux — minimal kernel payload; maintained x86 coreboot targets use a separate initrd.cpio.xz, while ppc64/Talos II bundles the initrd into zImage.bundled
• busybox — core utilities
• kexec — Linux kernel executor (loads kernels from boot partition, USB, network)
• tpmtotp — TPM-based TOTP/HOTP one-time password generator
• cryptsetup — LUKS disk encryption

The full build also includes: lvm2, tpm2-tools, flashrom/flashprog, dropbear (SSH), fbwhiptail (GUI), qrencode, and many others. See individual modules/* files and board configs for the complete picture.

We also recommend installing Qubes OS, although there Heads can kexec into any Linux or multiboot kernel.

Notes

• Building coreboot's cross compilers can take a while. Luckily this is only done once.
• Reproducibility-oriented mechanisms are enabled, but bit-identical output must be demonstrated with comparable same-commit builds and recorded artifact hashes.
• Current tested and maintained boards are tracked in doc/BOARDS_AND_TESTERS.md. Board targets themselves live under boards/.
• Xen does not work in QEMU. Signing, HOTP, and TOTP do work; see below.
• Blob requirements are board- or board-family-specific. Check the relevant documentation under blobs/ for the target you are building.
• Purism boards use Purism-managed coreboot blob paths from the Purism fork (for example 3rdparty/purism-blobs/... via CONFIG_IFD_BIN_PATH and CONFIG_ME_BIN_PATH in config/coreboot-librem_*.config). Heads should not maintain those vendor blob payloads. Runtime firmware notes for Librem blob jail are in blobs/librem_jail/README.
• Lenovo xx20 boards such as X220 and X230 use the shared xx20 blob flow documented in blobs/xx20/readme.md. X220-specific notes are in blobs/x220/readme.md.
• Other boards can source blobs from board-family directories under blobs/ (for example xx20/xx30/xx80, t420, t440p, w541) or from fork-specific paths configured in coreboot configs (for example Dasharo boards using 3rdparty/dasharo-blobs/...). Vendor blob payloads remain maintained by their upstream vendors/forks.
• T480 and T480s blob requirements are documented in blobs/xx80/README.md. Other families have their own docs under blobs/, for example t420/, t440p/, and w541/.

QEMU

OS booting can be tested in QEMU using a software TPM. HOTP can be tested by forwarding a USB token from the host to the guest.

For more information and setup instructions, refer to the qemu documentation.

coreboot console messages

The coreboot console messages are stored in the CBMEM region and can be read by the Linux payload with the cbmem --console | less command. There is lots of interesting data about the state of the system.