2016-08-03 03:29:46 +00:00
2016-07-25 13:06:36 +00:00
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
2016-08-03 03:29:46 +00:00
* Move the root of trust into hardware (or at least the ROM bootblock)
2016-07-25 13:06:36 +00:00
* Measure and attest to the state of the firmware
* Measure and verify all filesystems
2016-12-26 21:29:36 +00:00
2016-08-03 03:29:46 +00:00
2017-01-29 21:44:23 +00:00
NOTE: It is a work in progress and not yet ready for non-technical users.
2016-08-03 03:29:46 +00:00
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.
2016-07-25 14:08:53 +00:00
2016-12-26 21:29:36 +00:00
More information is available in [the 33C3 presentation of building "Slightly more secure systems" ](https://trmm.net/Heads_33c3 ).
2016-08-06 22:45:56 +00:00
2016-08-14 16:57:54 +00:00
Building heads
===
2017-01-29 21:44:23 +00:00
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
2017-03-03 14:13:27 +00:00
little slow since it will clone the `musl-cross` tree and build gcc...
2017-01-29 21:44:23 +00:00
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:
* [musl-libc ](https://www.musl-libc.org/ )
* [busybox ](https://busybox.net/ )
* [kexec ](https://wiki.archlinux.org/index.php/kexec )
* [mbedtls ](https://tls.mbed.org/ )
* [tpmtotp ](https://trmm.net/Tpmtotp )
2017-03-06 12:59:06 +00:00
* [coreboot ](https://www.coreboot.org/ )
2017-01-29 21:44:23 +00:00
* [cryptsetup ](https://gitlab.com/cryptsetup/cryptsetup )
* [lvm2 ](https://sourceware.org/lvm2/ )
* [gnupg ](https://www.gnupg.org/ )
* [Linux kernel ](https://kernel.org )
* [Xen hypervisor ](https://www.xenproject.org/ )
We also recommend installing [Qubes OS ](https://www.qubes-os.org/ ),
although there Heads can `kexec` into any (?) Linux or
[multiboot ](https://www.gnu.org/software/grub/manual/multiboot/multiboot.html )
kernel.
2016-08-14 16:57:54 +00:00
Notes:
2016-08-06 22:45:56 +00:00
---
2016-08-14 16:57:54 +00:00
* Building coreboot's cross compilers can take a while. Luckily this is only done once.
2017-01-29 21:44:23 +00:00
* Builds are finally reproducible! The [reproduciblebuilds tag ](https://github.com/osresearch/heads/issues?q=is%3Aopen+is%3Aissue+milestone%3Areproduciblebuilds ) tracks any regressions.
2016-12-13 18:36:05 +00:00
* 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.
2016-08-14 16:57:54 +00:00
* Booting Qubes requires patching Xen's real mode startup code
2017-01-29 21:44:23 +00:00
see `patches/xen-4.6.3.patch` and adding `no-real-mode` to start
2016-08-14 16:57:54 +00:00
of the Xen command line. Booting or installing Qubes is a bit hacky and needs to be documented.
2016-08-06 22:45:56 +00:00
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.
2016-08-14 16:57:54 +00:00
2016-12-13 17:02:35 +00:00
coreboot console messages
2016-08-14 16:57:54 +00:00
---
2016-12-13 17:02:35 +00:00
The coreboot console messages are stored in the CBMEM region
2016-08-14 16:57:54 +00:00
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.
