Heads build system is reextracting archives and reapplying patches on each iteration. CircleCI optimizes building time by providing cache mechanisms and forces users to build a target under an hour. This is to force Open Source projects (free tier) to not be leechers of the free tier. In the past days, CircleCI bails on building coreboot 4.11 boards because some files being cached are already being present (created files from patches). In those, two files were unwanted artifacts, recreated on top of coreboot 4.11 extracted original files (undesired .orig files), while bailing on the creating of src/security/tpm/sha1.c from patches/coreboot-4.11/0001-Add-Heads-TPM-measured-boot-support.patch. Hopefully, this is CircleCI having a maximum of 3 automatically entered input (it fails on the 3rd)... And this fix will permit src/security/tpm/sha1.c and src/security/tpm/sha1.h to be skipped if existing. Below, we see that CircleCI fills patch prompts with EOF 2 times, and then waits for input and then timeouts. Here is the failing log trace from https://app.circleci.com/pipelines/github/tlaurion/heads/990/workflows/f2a430fd-dc8c-4e95-abe3-364a0e825533/jobs/4914/parallel-runs/0/steps/0-103: Exerpt of that log: if [ -d patches/coreboot-4.11 ] && [ -r patches/coreboot-4.11 ] ; then for patch in patches/coreboot-4.11/*.patch ; do echo "Applying patch file : $patch " ; ( cd /root/project/build/coreboot-4.11/ ; patch -p1 ) < $patch || exit 1 ; done ; fi Applying patch file : patches/coreboot-4.11/0000-cpu-x86-smm-Use-PRIxPTR-to-print-uintptr_t.patch patching file src/cpu/x86/smm/tseg_region.c Applying patch file : patches/coreboot-4.11/0001-Add-Heads-TPM-measured-boot-support.patch patching file src/Kconfig The next patch would create the file src/Kconfig.orig, which already exists! Assume -R? [n] EOF Apply anyway? [n] EOF Skipping patch. 1 out of 1 hunk ignored patching file src/include/program_loading.h patching file src/lib/cbfs.c patching file src/lib/hardwaremain.c Hunk #2 succeeded at 549 (offset 8 lines). patching file src/lib/rmodule.c patching file src/security/tpm/Makefile.inc The next patch would create the file src/security/tpm/sha1.c, which already exists! Assume -R? [n] make: *** [Makefile:507: /root/project/build/coreboot-4.11/.canary] Hangup context deadline exceeded
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
Please refer to Heads-wiki for your Heads' documentation needs.
Building heads
make BOARD=board_name
where board_name is the name of the board directory under ./boards
directory.
In order to build reproducible firmware images, Heads builds a specific
version of gcc and uses it to compile the Linux kernel and various tools
that go into the initrd. Unfortunately this means the first step is a
little slow since it will clone the musl-cross-make
tree and build gcc...
Once that is done, the top level Makefile
will handle most of the
remaining details -- it downloads the various packages, verifies the
hashes, applies Heads specific patches, configures and builds them
with the cross compiler, and then copies the necessary parts into
the initrd
directory.
There are still dependencies on the build system's coreutils in
/bin
and /usr/bin/
, but any problems should be detectable if you
end up with a different hash than the official builds.
The various components that are downloaded are in the ./modules
directory and include:
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.
- Builds are finally reproducible! The reproduciblebuilds tag tracks any regressions.
- Currently only tested in QEMU, the Thinkpad x230, Librem series and the Chell Chromebook.
** Xen and the TPM do not work in QEMU, so it is only for testing the
initrd
image. - Building for the Lenovo X220 requires binary blobs to be placed in the blobs/x220/ folder. See the readme.md file in that folder
- Building for the Librem 13 v2/v3 or Librem 15 v3/v4 requires binary blobs to be placed in the blobs/librem_skl folder. See the readme.md file in that folder
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.