Brussels / 4 & 5 February 2023


Heads - status update!

What is Heads

Heads is a secure runtime environment and a build system; a build recipe cookbook, which boards configurations instructs which modules to be incorporated in the mix needed for specific platform board configuration.

Heads takes advantage of the linux kernel and common linux tools to create its runtime environment, including kexec, busybox, whiptail, cryptsetup, flashrom, LVM, the GPG toolstack, and other important and already existing tools to empower its runtime environement.

The typical output of a build are a packed initramfs and kernel, included inside a coreboot ROM image as its payload. Depending on the architecture/chipsets of a platform, it also integrates neutered/deactivated Intel ME/CSME binary blob (platform dependent), generated Gigabit Ethernet (GBE) configuration blob and an unlocked descriptor (IFD). The produced firmware images requires the platform to be flashed once externally to overwrite the origin flash chip(s) content, more specifically to overwrite locked IFD and ME/MCSE regions and to maximize the BIOS region to the extent of liberated Intel ME firmware region. Heads firmware upgrades can then happen internally for the lifetime of the platform.

Why Heads

Heads take advantage of coreboot measured boot in Static Root of Trust (SRTM) mode as a measurement base, which currently measures itself as early as possible, normally from bootblock(or romstage) into TPM a singleregister (PCR2). Heads payload is then executed after measured and extends TPM with its own measurements in distinct PCRs in the goal of sealing secrets in TPM's distinct NV regions. Kernel modules are measured prior to being loaded, LUKS drive(s) headers are measured if a TPM disk encryption key is configured, while going to the Recovery shell invalidates the TPM measurements by the same TPM extend mechanism.

From a user standpoint, those sealed secrets enables oneself to validate the integrity of the firmware either through TOTP code shown on screen on its smartphone or through HOTP (which challenges validity against supported enabled HOTP USB Security dongles). Another TPM sealed secret enables the user to release an additional LUKS disk encryption key only if the firmware is intact, that kernel modules loaded and Headers are consistent to sealed state and only if provided passphrase matches. Heads also validates user detached signed /boot digests against its fused in rom public key, which guarantees both integrity and authenticity of the trusted boot configuration prior of kexec’ing into it.

A lot happened since 2020... Let’s cover current state and where the project is heading!

What’s new?

  • Maximized boards vs Legacy boards, or how to dodge blob redistribution legal limitations
  • Whiptail/FBWhiptail: one graphical interface (GUI) to rule them all!
  • OEM Factory reset/Re-Ownership wizard upstreamed
  • QEMU/KVM board configurations with swtpm and USB Security dongle support to ease development/testing

What's next?

  • TPM2 support on QEMU/KVM and SWTPM.
  • A better build system to guarantee reproducible builds based on NixOS if everything goes well...
  • Clean room, in ram GPG key generation with backup/restore/USB thumb drive emergency usage capabilities from encrypted LUKS container to restore GPG key material on USB Security dongles upon replacement reception/acquisition later on (No more USB Security dongle strong requirement to use Heads while still highly recommended).
  • Authenticated Heads recovery shell, USB boot and more!
  • Finally: flash write protection options!
    • Platform chipset locking (only Heads can flash firmware)
    • SPI Write protection, permitting to write protect coreboot’s bootblock region (requires external flashing when coreboot version bumps happen under Heads. For the most paranoid only!)
  • International keyboard support
  • On demand MAC randomization inside of Heads, overwriting GBE region inside of firmware. Persistence across firmware upgrades.


Project homes


Photo of Thierry Laurion Thierry Laurion