Heads main menu

Left: laptop/workstation. Right: server (BMC/SSH/Console) Heads booting on qemu-fbwhiptail-tpm2-hotp and qemu-whiptail-tpm1

Support the Project

Heads and this wiki are free and open source, but keeping them maintained is ongoing work that is not free. Support via GitHub Sponsors (tlaurion) or Open Collective (Insurgo). See Supporting the Project on the Community page for details.

Overview

Heads is an open source custom firmware and OS configuration for laptops and servers that aims to provide slightly better physical security and protection for data on the system. Unlike Tails, which aims to be a stateless OS that leaves no trace on the computer of its presence, Heads is intended for the case where you need to store data and state on the computer.

ch341a_flashing

Heads is not just another Linux distribution – it combines physical hardening of specific hardware platforms and flash security features with custom coreboot firmware and a Linux boot loader in ROM. This moves the root of trust into the write-protected region of the SPI flash and prevents further software modifications to the bootup code (and on platforms that support it, Bootguard enforces verified boot of the firmware). Controlling the first instruction the CPU executes allows Heads to measure every step of the boot firmware and configuration into the TPM, which makes it possible to attest to the user or a remote system that the machine has not been tampered with. While modern Intel CPUs require binary blobs to boot, these non-Free components are included in the measurements and are at least guaranteed to be unchanging. Once the system is in a known good state, the TPM is used as a hardware key storage to decrypt the drive.

Additionally, the hypervisor, kernel and initrd images are signed by keys controlled by the user. While all of these firmware and software changes don’t secure the system against every possible attack vector, they address several classes of attacks against the boot process and physical hardware that have been neglected in traditional installations, hopefully raising the difficulty beyond what most attackers are willing to spend.

33c3

Conferences

  • 2016 - 33C3 - Trammel Hudson - Heads Presentation
    Abstract Trammel Hudson introduces Heads at 33C3 — an open-source firmware and Linux-based bootloader built on coreboot that establishes a hardware root of trust in a 4MB ROM. The talk catalogues specific attack classes and Heads' mitigations: Thunderstrike (DMA over Thunderbolt rewriting SPI flash — countered by IOMMU/VT-d enabling and coreboot disabling bus mastering before handoff); Lighteater, Dark Jedi, Speedracer (direct SPI flash overwrite via software — countered by hardware write-protect bits BP0-BP3 and disconnecting the WP# pin from the motherboard); Intel ME privilege escalation (countered by ME neutralization: stripping the ME firmware to the CPU bringup module only, removing the network driver and Java bytecode interpreter); Option ROM attacks (countered by disabling Option ROM execution entirely, using native Linux drivers instead). Walks through the boot chain: coreboot's three stages (bootblock in ASM sets up cache-as-RAM, romstage initializes DRAM and TPM, ramstage enumerates devices and jumps to the payload) all extend measurements into TPM PCRs. The Heads payload — a Linux kernel in ROM — extends further measurements, then the TPM seals disk encryption keys and a TOTP shared secret to those PCR values. On clean boot, the TPM releases the secret; Heads generates a 6-digit TOTP code displayed on screen for the user to verify against their phone ("remote attestation for humans"). Additional mechanisms: GPG-signed kernel/initrd for /boot verification with user-controlled keys on OpenPGP smartcards, dm-verity signed hash trees for read-only root filesystem integrity, Shamir's Secret Sharing (3-of-5) for LUKS key recovery. Includes a live demo flashing and booting Heads on a ThinkPad. Boot time: under 1 second to interactive recovery shell.
  • 2017 - 34C3 - Trammel Hudson - LinuxBoot Presentation
    Abstract Trammel Hudson presents LinuxBoot at 34C3: replacing the entire UEFI DXE/BDS/TSL/RT firmware stack with a Linux kernel and a choice of runtimes, reusing only the vendor SEC/PEI phases (including Intel FSP and AMD PI blobs) for memory controller and early CPU initialization. Two runtimes demonstrated: Heads (shell-script based, adding TPM measured boot, GPG-signed /boot verification, and kexec) and NERF (Go-based, developed by Ron Minnich — replaces shell scripts with just-in-time compiled Go for memory safety, better testability, and a more robust language at the firmware layer). NERF started by Ron Minnich (author of LinuxBIOS) at Google in January 2017; ported to multiple manufacturers' servers, demonstrating general portability. Boot time comparison: OpenCompute Winterfell server drops from 7 minutes with vendor UEFI to 20 seconds with LinuxBoot; Intel S2600 reaches a serial shell in about 20 seconds. Architecture: vendor PEI → Linux kernel in flash → runtime (Heads or NERF) → kexec into target OS. Key benefits: any Linux device, filesystem, or protocol works out of the box (no need to reimplement drivers in firmware); reproducible bit-for-bit builds; user-controlled keys replace vendor-controlled signing. Heads adds TPM-based measured boot extending PCRs from coreboot through the payload, GPG for detached /boot signature verification, and Keylime for remote attestation (servers prove to user-controlled systems that the firmware matches what they expect). Also covers network and iSCSI drivers for diskless compute node servers, and work to disable runtime ME before starting Linux.
  • 2018 - Platform Security Summit - Trammel Hudson - LinuxBoot : Firmware is the new software
    Abstract Trammel Hudson presents LinuxBoot: replacing proprietary, closed-source vendor UEFI firmware with Linux in flash. Drawing parallels to the UNIX wars where Linux took over the server space, he argues the same fundamental shift will happen in firmware. Traces roots from Ron Minnich's LinuxBIOS at Los Alamos (1990s), through Google's coreboot powering all Chromebooks with TPM attestation, to the modern LinuxBoot collaboration between Google, Facebook, and Horizon. UEFI is a 30-year-old OS in its own right — firmware must be open, auditable, reproducible, and measured.

    Slides: pdf

  • 2019 - Platform Security Summit - Thierry Laurion - Accessible Security: An OEM approach to transferring device and secrets ownership
    Abstract How can non-experts benefit from cutting-edge security research when they can't read code or flash ROMs? Thierry Laurion presents an NLnet-funded initiative to preinstall Qubes OS ("reasonably secured OS") on "slightly more secured hardware" (Heads, me_cleaner, coreboot) to make state-of-the-art security accessible without requiring users to become security researchers. Covers: binary-free firmware with TPM and smartcard for transit tamper evidence and provable device re-ownership, user-controlled hardware ownership and empowerment, compartmentalization and binary blob realities, and the FSF RYF vocabulary gap (neutered/deactivated/deleted ME).
  • 2020 - FOSDEM - Thierry Laurion - Heads OEM device initial ownership of platform/transfer of ownership (Re-Ownership concept)
    Abstract Current status and future plan: a call for collaboration. Presents the Insurgo Initiative — bridging QubesOS and Heads to make security accessible via NLnet funding. Covers the OEM reownership workflow (TPMTOTP over smartphone, HOTP over Librem Key/Nitrokey Pro 2 for pre-shipment attestation, re-ownership wizard), the maintainer burnout crisis (coreboot dropping KGPE-D16, LineageOS dropping i9300 as warnings), the need for PPC64le/Talos II QubesOS support, and the Insurgo OpenCollective model committing 25% of net profit to open-source bounties. A call for developers and maintainers to sustain privacy-focused projects.

    Slides: odp | Paper: pdf

  • 2020 - SOCALINUXEXPO - Kyle Rankin - Tamper Evident Firmware with User-controlled keys
    Abstract Kyle Rankin (Purism CSO) presents Heads' tamper evident boot model: unlike UEFI Secure Boot which blocks untrusted code using vendor controlled keys, Heads detects tampering and alerts. "Heads does not provide tamper proofing — it makes it difficult to tamper in an undetectable way," analogous to a tamper evident seal that a box cutter can defeat, but not without leaving evidence. Stage one — BIOS integrity via TPM + TOTP/HOTP. coreboot measures each boot stage into TPM PCR 2 (cumulative hashing). During setup, Matthew Garrett's tpmtotp generates a TOTP/HOTP secret, seals it in the TPM, and displays a QR code. The user photographs the QR code with a standard authenticator app — the system now authenticates itself to the user. At each boot, Heads displays a 6-digit code on screen; the user compares against their phone. For the Purism Librem Key (developed with Nitrokey), the secret is stored on the key over USB; the key independently computes the expected HOTP code; if it matches, the key blinks green; if not, it blinks red continuously (colorblind differentiated). Crucially, when tampering is detected, Heads shows a red screen but does not lock the user out — "it's more alerting you to tampering." The key, not the screen, is the trusted element — "you can't trust the computer. What you can trust is this key." Stage two — /boot file integrity via GPG. A full GPG keyring is embedded in the 4-16 MB SPI flash. Heads stores checksums of every file in /boot (kernel, initrd, GRUB config) in a GPG signed manifest. On legitimate kernel updates, the user plugs in a hardware OpenPGP smart card (Librem Key, Nitrokey, YubiKey) to sign changed files again. If an attacker implants a kernel rootkit or backdoored initrd, the signature check fails before kexec. Hardware: ThinkPad X200 flashed via Pomona clip + Raspberry Pi, Purism Librem laptops. Also covers fleet deployment (multiple GPG keys for shared enterprise management), TPM based LUKS secret unlocking, and the tradeoff between fuse blowing for read only firmware versus retaining update capability.
  • 2023 - FOSDEM - Thierry Laurion - Heads status update
    Abstract Thierry Laurion presents the state of Heads at FOSDEM 2023. What Heads is: a secure runtime environment and build system — a "recipe cookbook" where board configuration files instruct which modules to include. Builds produce a packed initramfs and kernel inside a coreboot ROM image plus neutered/deactivated Intel ME/CSME, generated GBE configuration blob, and unlocked IFD descriptor. Requires one external flash to overwrite locked IFD/ME regions and maximize the BIOS region; all subsequent upgrades happen internally. Why Heads: coreboot measured boot in Static Root of Trust (SRTM) mode extends PCR2 from bootblock/romstage; the Heads payload extends distinct PCRs to seal secrets in TPM NVRAM regions. Two TPM sealed secrets, one shared by TOTP and HOTP, plus a LUKS disk encryption key: a TOTP code displayed on screen for smartphone verification, an HOTP challenge against USB security dongles (Librem Key, Nitrokey Pro 2), and a LUKS disk encryption key released only when firmware is intact, kernel modules match, LUKS headers are consistent, and the user passphrase is correct. Detached GPG signed /boot digests are verified against a public key fused into the ROM. Kernel modules are measured before loading. What's new since 2020: maximized vs legacy board configs, unified Whiptail/FBWhiptail GUI, OEM factory reset and reownership wizard upstreamed, QEMU/KVM board support with swtpm and USB security dongle pass through enabling full testing without hardware. What's next: TPM2 support on QEMU/KVM and swtpm, NixOS based reproducible build system, clean room in RAM GPG key generation with backup/restore, authenticated recovery shell with USB boot, flash write protection, international keyboard support, on demand MAC randomization.

    Slides: odp | Paper: pdf

  • 2024 - QubesOS mini-summit - Thierry Laurion - Heads rolling release : roles of upstream and downstream forks (Design Session)
    Abstract Thierry Laurion (Heads maintainer) leads a design session on the tension between Heads' rolling-release model and downstream vendor needs. The nlNet-funded reproducible Docker build infrastructure guarantees that for any merged commit, anyone can rebuild the exact same bit-for-bit ROM at any future time — a direct enabler of rolling release. Downstream vendors (NovaCustom, Nitrokey, others selling pre-installed Heads) cannot track master indefinitely; they need stable, supported, tested releases with predictable lifecycles. Laurion characterizes open-source users as "beta testers by default" who want bleeding-edge features and are willing to self-build, while commercial customers require validated firmware that ships once per year. Concrete proposals: a feature-freeze cycle with cut-off dates, a private invite-only beta testing program (NovaCustom reports "exceeded my expectation" for engagement and bug-catching speed), and automated regression testing on real hardware before release. Key challenges: Heads depends on four coreboot forks, making version pinning nontrivial, and automated firmware testing on laptops faces hardware obstacles (HDMI unavailable, unreliable serial). "If we arrive near a feature freeze, it would require the communities to actually join the beta testing effort."
  • 2024 - QubesOS mini-summit - Jan Suhr & Thierry Laurion - Future of Measured Boot such as Heads (Design Session)
    Abstract Jan Suhr (Nitrokey) leads a design discussion on Heads' measured-boot architecture: a coreboot + Linux-payload firmware using a USB security dongle as root of trust to mitigate evil-maid attacks, paired with Qubes OS on Nitropads. The central UX pain point: users must re-sign after every kernel update because Heads verifies exact hashes of /boot files. "If you compare it to ordinary PC users, this is in fact complicated — this is a burden," Suhr states, noting this blocks mainstream adoption. Alternative architectures debated: UKI (Unified Kernel Image) could solve the resigning problem by reducing changed files from five to one and enabling signature-based rather than hash-based verification. Porting Heads' logic to UEFI/TPM was discussed, but would require reimplementing all the bash-based measurement logic — "if funding is unlimited, everything's possible," Laurion quips. DRTM was considered but dismissed as server-only and requiring PCI-device reset. OpenPGP card support in UEFI was explored but deemed "quite expensive" (requiring Rust reimplementation). The group converged that making attested boot mainstream requires: kernel updates without manual resigning, richer user feedback on what changed in grub configuration, OS-side signing integration, and potentially UKI adoption.
  • 2026 - BSMCONF - Dodoid - Flashkeeper - Manage and Protect your SPI Flash
    Abstract Dodoid, embedded developer, PCB designer, free-software sysadmin and system integrator, and administrator of the 15h.org community (100 or more KGPE-D16 and other fam15h users, maintainers of coreboot-15h), and an occasional upstream coreboot contributor, presents Flashkeeper at the Boot Security Mastery Conference (BSMConf) 2026, a project he has worked on for a while with Thierry Laurion of Insurgo, a platform security researcher and long-time maintainer of LinuxBoot and Heads, who offered the Insurgo PrivacyBeast X230, one of the few Qubes OS certified laptops. He opens with a what if: a standardized, open, well-documented expansion port on every motherboard, providing power and SPI on the same bus as the firmware flash, in a standard form factor, adopted by nearly every vendor. That port does not exist. Close things do: SPI TPM headers exist but are vendor dependent, and some lack the BIOS chip select (he showed a TPM module he designed for MSI boards that also exposes the BIOS flash). Older boards with DIP flash take interposer boards, but they are rare, 3mdeb used to sell one for the KGPE-D16 with a write-protect header, and DIP flash chips are hard to find. The one near-universal interface is the flash chip itself: most modern boards have an 8-pin SPI flash (WSON-8 8x6 or SOIC-8 208-mil dominate, WSON 6x5 and SOIC 150-mil are uncommon), the pinout is essentially universal, pitch is usually 1.27 mm, width usually about 8 mm, and manufacturers often draw flexible footprints with exposed ground pads or long pads to allow part substitution. Chip clips exploit this, but WSON and SOIC clips do not interoperate, WSON clips are finicky, clips are unreliable even short term (one flew off the desk at 80% of a flash run), too big to leave in a running system (laptops, chips under heatsinks), and sometimes do not fit at all when passives are close. The Flashkeeper answer is a chip adapter: a 2-layer flex PCB soldered permanently on top of the host flash, with eight flexible legs, four per side, reaching down and soldering to the same pads the chip uses, with variants optimized per package. A breakout (SOIC or WSON) brings the bus out on a ZIF connector. His example is an AAEON UP Squared, an industrial SBC with an Apollo Lake SoC and a coreboot port, whose flash sits under the CPU heatsink: with the breakout installed the heatsink goes back on, the cable runs out of the case, and the board flashes from the desk (his photo shows it going through a small adapter board into a CH341A). He has sent breakouts to laptop owners whose flash is only reachable with the machine fully apart, with the cable run out through a USB port or any chassis hole. A write-protect adapter puts a switch on the chip that holds WP# low. Most SPI flash chips support partial write protection, set in the status registers with flashrom, for example to protect the coreboot bootblock region, but it only enforces if WP# is held low, and many motherboards offer no user access to it, though some have jumpers and some Chromebooks a screw. So the chip just gets a switch. This was the first Flashkeeper item: Laurion asked Dodoid to build it while working on Heads bootblock write protection, replacing the solder blobs and jumper wires people improvised. Then the talk goes bigger: a microcontroller on the chip could monitor reads, debug SPI transactions, read and write the flash remotely, authenticate external reprogramming, and verify flash contents at boot, and an FPGA can do all of that. Space is about 25 mm squared, and the module must be self-contained: 3.3 or 1.8 volts from the host with no choice, its own clocks, its own voltage regulation, its own bitstream and firmware storage, and its own development port. Flex PCBs have large minimum feature sizes, and rigid flex is a quote-only item from a few vendors, so the answer is a rigid system-on-module mounted as a component on the flex adapter. The SoM carries a Lattice iCE40UP5K FPGA, chosen for a fully free yosys and nextpnr toolchain, on-chip SPRAM, a built-in high frequency oscillator, about three voltage rails, and one-time-programmable non-volatile configuration memory that after programming refuses other bitstreams and does not let the bitstream be read out, a useful security property; a TI TPS7A20 regulator; a Micro-Crystal RV-3028-C8 real-time clock, because there is no good way to access the host RTC and no clear way to trust it; and a Renesas AT25DF041B SPI flash for the FPGA's own bitstream and firmware, mounted less than a millimeter above the host flash. The SoM is 7.15 by 3.30 mm, six layers, custom LGA-25 footprint, designed in KiCAD, 2 mil trace spacing, 0.4 mm BGA pitch, 0201 passives, no blind or buried vias, on the standard JLCPCB process. It was too small for the fab minimum, so he designed a custom panel with ten SoMs, fiducials, and handling rails to reach 70 by 70 mm, with snap-off development breakout headers. The FPGA chip adapter puts the SoM on the bottom against the host flash, with a 10-pin ZIF debug connector on top. The flex part can fold away or be cut off with scissors for height-constrained builds. A tail adds an onboard speaker for beeps and alerts, possibly coreboot's SPKCON, plus a TDK CeraCharge solid-state battery and charge regulator that keeps the RTC running with the host off, recharged whenever the host runs, expected to last a bit over a month. The FPGA runs a modified PicoSoC: a PicoRV32 RISC-V core in RV32Izmmul (hardware multiply, software divide), 128 KiB of the iCE40 SPRAM, an 8 KiB boot ROM in the bitstream itself, which matters because SPRAM cannot be initialized from the bitstream, so one-time-programmed code can load and verify a firmware image from the external flash instead of trusting it, a ring-oscillator entropy source, and memory-mapped access to both the onboard and host SPI flash. The Flashkeeper firmware reads, writes, and debugs the host flash, includes TweetNaCl lightweight cryptography, and has an extensible Forth-like stack shell (EDE) over serial, not a compliant Forth. It is an FPGA, so whatever you want. Applications: authenticated external flashing; flash image verification; coreboot bootblock verification, coming very soon, which at runtime sniffs the SPI bus, builds a copy of the bootblock in memory, and verifies it against the actual bytes the host reads, and at rest masters the SPI bus with the host powered off and reads the flash directly; logging and debugging SPI flash and SPI TPM transactions, the TPM usually shares the bus; and a coreboot spiconsole decoder, since coreboot can output its console over the SPI bus. The point against vendor verification like Intel Boot Guard: those rely on code the user does not control, in ROM or signed with keys the user does not have. The Flashkeeper FPGA is a general-purpose computer under user control, fully free and open hardware, software, and gateware, built with entirely open toolchains (KiCAD, FreeCAD, yosys, nextpnr, GCC). And fused and read-only do not have to mean proprietary: you develop with the bitstream in flash as long as you like, then burn it to NVCM at home with your own gateware, boot ROM, firmware, and secrets, and nobody can extract it or make the FPGA run anything else. The live demo resets the FPGA over serial with tio, shows the password prompt (no points for guessing what the password is), runs help, pushes 2 and 2 onto the Forth stack and gets 4, reads the host flash ID with HFID (a Windbond chip in his setup), benchmarks the PicoRV32 core, and pulls bytes from the onboard entropy source; the shell can read and write the host flash directly. For authenticated external reprogramming he exits the shell, the FPGA still answers on the serial port with my name is Flashkeeper FPGA, identifies the host flash, and he skips the full read/verify cycle so the audience does not have to sit through it; the password is what stops anyone else from reprogramming the flash, so a laptop you carry can be reprogrammed from outside the case without a cable left in the chassis. Status: the hardware is fully open source, the firmware is open source too, not every application described is done, but everything in the demo works. Repositories are at git.15h.org/Flashkeeper/flashkeeper and github.com/linuxboot/flashkeeper, the site is flashkeeper.org, there is a Matrix room, and contributions, questions, and testing are welcome. Q&A: install guides exist for the chip adapters, the FPGA module guide is planned for the website. On sales and distribution, the iCE40 FPGAs are almost impossible to buy right now (he cannot imagine how they are used for AI, but they are being bought up for it), so he is hoarding his stock and plans a small production run, maybe ten units, as a beta program initially through Matrix, and is open to partners. A question asks whether the write-protect switch still works when the platform uses the flash in quad I/O mode: it is chip dependent, he doubts it works because the switch just pulls that IO low, the only idea is a series resistor if the flash chip overcomes it, he is not sure how flash chips handle the WP pin in quad mode, whether they ignore it or sample the last WP state from single mode, and status-register write protection in quad mode is less standard than the rest of the 25xx SPI flash protocol, so if you rely on write protection on a flash that runs in quad mode, verify that it actually holds.

    Slides: pdf

Papers

  • 2016 - BLOG - Trammel Hudson - Heads 33c3 - Bootstrapping slightly more secure systems
    Abstract Trammel Hudson's detailed walkthrough of the Heads project: boot firmware as the root of trust. Covers specific attacks (Thunderstrike over Thunderbolt, Lighteater/Dark Jedi/Speedracer SPI flash exploits), coreboot's three-stage boot process (bootblock/romstage/ramstage), the TPM measurement chain sealing disk encryption keys and TOTP secrets to PCRs, GPG-signed kernel/initrd verification with user-controlled keys on OpenPGP smartcards, Intel ME neutralization (stripped to CPU bringup only), and Shamir's Secret Sharing for key recovery. Philosophy: systems must be open, flexible, built on widely tested code, and reproducible — "most firmware is closed source, rarely updated, and potentially full of unfixable vulnerabilities."
  • 2017 - BLOG - Trammel Hudson - Linuxboot 34c3 - Bringing linux back to the server BIOS with LinuxBoot
    Abstract LinuxBoot replaces the entire UEFI DXE/BDS/TSL/RT firmware stack with a Linux kernel and a runtime (Heads shell scripts or NERF Go-based userland), reusing only the vendor SEC/PEI phases (including FSP blobs) for early silicon init. Boot time comparison: OpenCompute Winterfell drops from 7 minutes (UEFI) to 20 seconds (LinuxBoot). NERF, developed by Ron Minnich, replaces shell scripts with just-in-time compiled Go for memory safety and better testability. Architecture: vendor PEI → Linux kernel in flash → runtime → kexec into target OS.
  • 2018 - Linux Journal - David Hendricks - LinuxBoot: Linux as firmware
    Abstract LinuxBoot replaces late-stage firmware with a Linux kernel and initramfs: instead of firmware implementing its own drivers for every boot medium, network interface, and filesystem, standard Linux drivers and userspace tools (wget, cryptsetup) handle OS loading. Created by Ron Minnich at Google (2017), became an official Linux Foundation project in January 2018. Contributors span Google, Facebook, Two Sigma, Horizon Computing, and 9elements. Key benefits: eliminates firmware driver bloat, avoids reimplementing sophisticated tools in firmware, replaces proprietary code with auditable Linux, lets organizations leverage existing Linux kernel expertise instead of requiring firmware specialists.
  • 2018 - Linux Journal - Michael J. Hammel - LinuxBoot: Custom Embedded Linux Distributions
    Abstract A practical guide to building custom embedded Linux distributions from scratch. Walks through the full bring-up chain: Crosstool-NG for cross-toolchains (kconfig menus for architecture, endianness, FPU), U-Boot for ARM / coreboot for x86 as second-stage bootloader, BusyBox as lightweight utility collection for initramfs, and Buildroot as the metabuild orchestrator handling all dependency management with support for Python, PHP, Lua, and Node.js. Argues that metabuild tools have matured enough to make custom distros feasible for IoT developers — avoiding the dependency nightmares of stripping down off-the-shelf distributions.
  • 2019 - Linux Journal - Kyle Rankin - Tamper-Evident Boot with Heads
    Abstract Kyle Rankin's deep dive into Heads' two-layer tamper-evident boot. Layer 1 — BIOS integrity: Heads seals a random TOTP/HOTP secret inside the TPM bound to PCR measurements of the BIOS code. On clean boot, the TPM releases the secret and Heads displays a 6-digit TOTP code for the user to verify against their phone; on tampered boot, the TPM refuses and error is shown. Layer 2 — /boot file integrity: user-controlled GPG keys on an OpenPGP smartcard sign a hash file of all /boot contents (kernel, initrd, GRUB config); Heads verifies before kexec. Unlike UEFI Secure Boot (vendor-controlled keys that block untrusted code), Heads detects tampering and alerts, while still allowing any software. Requires coreboot/LinuxBoot hardware with a TPM chip; supported boards included X220, X230, Librem laptops, and select servers.
  • 2023 - BLOG - Michael Atfield - Trusted Boot (Anti-Evil-Mail, Heads and Pureboot
    Abstract Demystifies trusted boot technologies for a general audience. Explains how Heads and PureBoot (Purism's downstream fork) chain coreboot, TPMs, TOTP/HOTP, and hardware security keys to cryptographically verify system integrity against physical Evil Maid attacks. Contrasts the cypherpunk-friendly model (user holds the keys, open-source, reproducible builds) with enterprise UEFI Secure Boot (vendor holds the keys, closed-source, opaque trust).
  • 2025 - Linux Foundation Member Summit - Ronald (Ron) Minnich - Deploying Linux as Firmware at Global Scale: Update
    Abstract Ron Minnich (creator of LinuxBIOS/coreboot, TSC Chair LinuxBoot) presents the case that proprietary firmware is an escalating security liability that must be replaced with open-source firmware. The UEFI vulnerability crisis: CVE mentions exploded from near-zero annually (0-4/year 1999-2014) to 59 in 2024 and 69 in 2023. Alex Matrosov of binarly.io explains these are severe underestimates — "firmware-related issues are either mislabeled or not labeled at all" in the NVD, placing the true count at 750 CVEs in just 2.5 years. The threat is not theoretical: the TCSL rootkit audit analyzed 100,000 UEFI images and found rootkits, phone-home callbacks, web servers, and SMTP clients pre-installed in firmware from Toshiba, Acer, Lenovo, Asrock, Razer, Clevo, American Megatrends, LG, Dell, ASUS, Gigabyte, Intel, Sony, HP, Apple, Alienware, and AMD. Specific exploits catalogued: Lenovo's factory-installed rootkit (2015), CosmicStrand UEFI firmware rootkit that "survives OS reinstalls," Thunderstrike (persistent Thunderbolt exploit), SMM Sinkhole, AMD PSP off-by-one exposing private keys across millions of platforms, Intel ME's trivial zero-length password bug across a billion systems, and CVE-2021-0144 spanning nine generations of Intel processors. Minnich argues this crisis is "by design" — UEFI's 1990s "drop-in-a-DXE" model with quadratic boot-time scaling is fundamentally broken. The LinuxBoot solution started at Google Jan 2017, deployed at global scale by Dec 2020: a Linux kernel with u-root initramfs (160+ Go commands including bash-compatible shell, sshd, HTTPS pxeboot 100x faster than TFTP) placed in flash via the Fiano/utk toolchain, which scriptably removes hundreds of unnecessary DXE drivers. The talk's summary: firmware is the perfect place to hide exploits; vendor promises of perfect code must not be believed; firmware must be open source; and critically, no firmware should keep running once Linux is booted — tools now exist to disable runtime ME, UEFI, and SMI within vendor firmware design constraints.
  • 2026 - Open Source Summit India - Manish Baing, Arun Mahendran (Lenovo) - An Introduction to coreboot and LinuxBoot: Building Modern Open Boot Stack
    Abstract Manish Baing and Arun Mahendran of Lenovo present the two-layer open boot stack replacing proprietary UEFI. The problem: vendor-locked "black box" UEFI builds derived from EDK II that users cannot inspect or modify; slow security patching where vulnerabilities fixed upstream languish until each vendor ships updates; and a bloated DXE (Driver Execution Environment) loading hundreds of tightly-coupled drivers, slowing boot and expanding the attack surface. Solution: coreboot, created by Ron Minnich in 1999 as LinuxBIOS and renamed in 2008, compiles multiple stages — bootblock (assembly, Cache-As-RAM setup), verstage (root of trust for verified boot), romstage (DRAM init), postcar (teardown CAR), ramstage (PCI, CPU, device init, hardware lockdown, write-protects boot media), and payload — into a CBFS image with LZMA compression, typically integrating vendor FSP (FSP-T/M/S) binaries for silicon init. coreboot distributions include Heads (Linux payload with TPM-based measured boot), Libreboot, Canoeboot, MrChromebox, Skulls, and [Dasharo](https://docs.dasharo.com/). LinuxBoot, started as NERF at Google in 2017, replaces UEFI DXE modules with a minimal Linux kernel and a Go-based initramfs built via u-root (source mode with on-the-fly Go compilation, or BusyBox mode producing one static binary), plus SystemBoot bootloaders (pxeboot for network boot via DHCP/HTTP, boot for finding local kernels) using kexec to hand off to the production OS. Build steps: git clone coreboot, make menuconfig, make to produce build/coreboot.rom; for LinuxBoot, go install u-root, generate initrd.cpio, verify dependencies (uuid-dev, nasm, acpica-tools), build with CONFIG_EFI_BDS, run make to produce build/$(BOARD)/linuxboot.rom. QEMU demo: qemu-system-x86_64 -machine q35 -nographic -kernel vmlinuz -initrd u-root.cpio.xz.

    Slides: pptx

Learn more about Heads