heads - A minimal Linux that runs as a coreboot or LinuxBo

项目说明

Heads: the other side of TAILS

!Heads booting on an x230

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 all filesystems

!Flashing Heads into the boot ROM

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 服务端,
external SPI flash programmers, possible risk of destruction and
significant frustration.

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

![Ask DeepWiki]()

Documentation

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

| Document | What it covers |
| --- | --- |
| doc/architecture.md | Component o, 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 | 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 , de config reference |
| doc/ux-patterns.md | 界面/UX con: 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 de 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 , TPM, LUKS, threat models |
| doc/keys.md | All keys and secrets: TPM owner, GPG PINs, Disk Recovery Key, LUKS DUK |
| doc/de.md | Commit con, coding standards, testing checklist |
| doc/build-freshness.md | Debugging stale builds: cpio composition, BCJ/XZ filters, |
| Hardware Compatibility — intended publication target | Not a working link: 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 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 tags are a for
git describe --tags (used at build time for artifact filenames):

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

Quick start (requires Docker CE):

From a non-interacti (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 (util-linux) allocates a pseudo-terminal (PTY) so docker run -ti has
a TTY in a non-interacti context; the command's output is still shown on
screen (stdout). The options used above:

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
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 de , 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,
package inputs, pinned timestamps/build flags, normalized archive
metadata, and a pinned Docker image on the canonical wrapper path. These reduce
common sources of but do not make one build's output inherently
bit-identical to another.

After the toolchain is a, the top-level Makefile downloads packages,
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 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, 网络)
* 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 (界面), qrencode, and many others. See indi 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 li 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 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 源码 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/...). blob payloads remain maintained by their upstream /forks.
* T480 and T480s blob requirements are documented in blobs/xx80/README.md. Other families ha 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.

项目信息

开发语言：Makefile

Star 数：1594

技术要点

该项目属于黑客技术方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕A minimal Linux that runs as a coreboot or LinuxBoot(UEFI's DXE replacement) ROM payload to provide a secure, flexible boot en for laptops, workstations and servers.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。