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
Trammell Hudson 24e54a65f6
Build GNU make-4.2 if the system make is the wrong version (issue ).
Change all of the builds to use $(MAKE) instead of the /usr/bin/make.

Download and build GNU make-4.2 if the wrong version is installed
on the system.

Re-invoke build/make-4.2/make with the target that was passed in once
the correct make has been built.
2017-01-27 18:00:50 -05:00
build porting Makefile to use a modular build system for each package 2016-08-02 19:25:47 -04:00
config enable CONFIG_NET, to allow cryptsetup to work (issue ) 2017-01-05 06:00:59 -05:00
initrd musl-libc patches to build a successfull qemu image 2017-01-04 10:31:27 -05:00
modules Build GNU make-4.2 if the system make is the wrong version (issue ). 2017-01-27 18:00:50 -05:00
packages ignore fetched files 2016-08-02 21:24:15 -04:00
patches Make kexec work with musl-libc. 2017-01-04 13:51:36 -05:00
.gitignore ignore modified .config files 2016-11-23 12:10:40 -05:00
cpio-clean reset nlinks as well since /dev was changing due to serial adapter hotplug 2016-08-16 09:13:09 -04:00
FAQ.md some frequently asked questions, with draft answers 2016-09-27 19:53:28 -04:00
fit-parse parse the Firmware Interface Table (FIT) on a ROM image 2016-12-01 13:57:35 -05:00
Makefile Build GNU make-4.2 if the system make is the wrong version (issue ). 2017-01-27 18:00:50 -05:00
populate-lib single line output for tracking which libraries go with which programs 2016-12-28 12:39:48 -05:00
README.md removed old info, added link to presentatoin 2016-12-26 16:29:36 -05:00
verity-sign mount /boot 2016-08-07 13:49:30 -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 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

Components:

  • coreboot
  • Linux
  • busybox
  • kexec
  • tpmtotp (with qrencode)
  • QubesOS (Xen)

The top level Makefile will handle most of the details -- it downloads the various packages, patches them, configures and builds, and then copies the necessary parts into the initrd directory.

Notes:

  • Building coreboot's cross compilers can take a while. Luckily this is only done once.
  • Builds are not reproducible; there are several issue with the reproduciblebuilds tag to track it.
  • Currently only tested in Qemu and on a Thinkpad x230. Xen and the TPM do no t 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 add no-real-mode to start of the Xen command line. Booting or installing Qubes is a bit hacky and needs to be documented.
  • Coreboot 4.4 does not handle initrd separately from the kernel correctly, so it must be bundled into the coreboot image. Building from git does the right thing.

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.