A minimal Linux that runs as a coreboot or LinuxBoot ROM payload to provide a secure, flexible boot environment for laptops, workstations and servers.
Go to file
2018-02-02 15:54:01 -05:00
bin move tools into bin/ directory 2018-01-19 14:17:26 -05:00
blobs checkpointing a config that boots to user space, but serial still does not work 2018-01-19 15:53:05 -05:00
build porting Makefile to use a modular build system for each package 2016-08-02 19:25:47 -04:00
config checkpointing a config that boots to user space, but serial still does not work 2018-01-19 15:53:05 -05:00
initrd Build the Heads/NERF firmware for the Dell R630 server. 2017-09-20 10:29:14 -04:00
modules fix url for LVM2 2018-02-02 15:54:01 -05:00
packages ignore fetched files 2016-08-02 21:24:15 -04:00
patches fix patch format for edk2/Makefile 2018-01-16 12:56:03 -05:00
.gitignore ignore temporary files 2017-10-05 15:17:24 -04:00
COPYING Add GPL license (issue ) 2017-02-26 10:53:11 -05:00
dev.cpio Build the Heads/NERF firmware for the Dell R630 server. 2017-09-20 10:29:14 -04:00
FAQ.md some frequently asked questions, with draft answers 2016-09-27 19:53:28 -04:00
Makefile move tools into bin/ directory 2018-01-19 14:17:26 -05:00
Makefile.nerf checkpointing a config that boots to user space, but serial still does not work 2018-01-19 15:53:05 -05:00
README.md Added blob directory for non-free blobs Also basic documentation for the binaries needed for the X220 and how the get to them 2017-05-01 10:49:45 -04:00

Heads boot ROM motd

Heads: the other side of TAILS

Heads is a configuration for laptops 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

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 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".

Building heads

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 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 and the Chell chromebook. ** Xen and the TPM do not work in QEMU, so it is only for testing the initrd image.
  • Booting Qubes requires patching Xen's real mode startup code see patches/xen-4.6.3.patch and adding no-real-mode to start of the Xen command line. Booting or installing Qubes is a bit hacky and needs to be documented.
  • Building for the Lenovo X220 requires binary blobs to be placed in the blobs/x220/ folder. See the readme.txt file in that folder

Signing with GPG

gpgv is a stripped down version of GPG that can be used to verify signatures without extraneous libraries. This works well with the Free Software workflow that we want to use.

gpg --clearsign roothash

The roothash and roothash.sig files can be embedded into the HDD image and then extracted at firmware boot time:

gpgv --keyring /trustedkeys.gpg roothash.sig roothash \
|| echo "FAILED"

The mount-boot script is a start at doing this automatically. There needs to be an empty block at the end of the partition that includes a signed script to be executed; typically it will contain the dm-verity parameters to build the dmsetup command line to mount /boot.

The boot script can't be stored in the boot filesystem since the dm-verity hashes that protect the filesystem would need to have their own hash pre-computed, which is not feasible with a good hashing algorithm. You could store the hashes in the ROM, but that would not allow upgrades without rewriting the ROM.

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.