f6d049b3c0
Heads buildstystem:
Makefile logic will download modules packages under ./packages, check itheir integrity, then extract it and patch extraction directory ONLY if no corresponding .*_verify files are found under ./packages directory. They are extracted under build/modulename-ver/ where patches are applied prior of building them.
build/module* .configured is written when packages are configured under build/modulename-ver/.configured
build/modules* .build is written when packages are built under build/modulename-ver/.build
CircleCI caching subsystem notes:
A cache name tag is calculated in the prep_env stage early at each beginning of a workflow, and consists of a cache name, appended by a calculated digest signature (which is the final hash of hashed files (the hash of a digest).
Look for the following under .circleci/config.yml:
"Creating .... digest statements" : they are basically files passed under sha256sum to create a digest.
restore_cache keys: they are basically a string concatenating: name + checksum of digest + CACHE_VERSION. Only the first cache is extracted following declared order.
save_cache keys: same as above, only saving non-existing caches. That is, skipping existing ones and creating missing ones.
A cache is extracted at the beginning of a workflow if an archive matches an archive name, which consists of a name tag + digest hash + CACHE_VERSION
A cache is created only at the end of a workflow ("Saving cache...").
Caches are specialized. Caches are linked to checkumming of some content. And the largest available cache is extracted on next workflow, only extracting the directories/files that were contained in that cache.
A workspace cache ("Attaching workspace..."), as opposed to a end workflow cache, is passed along steps that depends on prior workflow, as specified under CirclecI config. The current CircleCI config creates a workspace cache for:
make + gawk + musl-cross-make (passed along next)
the most massive board config for each coreboot version (passed along next)
which is finally leading to the workflow cache, specialized for different content that should not change across builds.
That is 3 caches
musl-cross-make and bootstrapping tools (builds make and gawk locally) as long as musl-cross module has same checksum
a coreboot cache, containing all coreboot building directories, as long as coreboot module and patches are having the same hashes
a global cache containing alla builds artifacts (build dir, install dir, musl-cross dir etc)
Consequently, a workspace cache contains all the files under a path that is specified. For heads running under CircleCI, this is ~/project, which is basically "heads" checked out GitHub project, and everything being built under it.
When a workflow is successful, save_cache is ran, constructing caches for digest hashes that are not yet saved (which corresponds to a hash matching muslc-cross module hash, coreboot+patches digest hash and another one for all modules and patches digest hash.
On next workspace iteration, pre_env step will include a "Restore cache" step, which will use the largest cache available and extract it prior of passing it as workspace caches. This is why there is no such different in build time when building on a clean build (the workspace caches layers are smaller, and passed along. This means saving it, passing it. next workspace downloads extracts and builds on top of those smaller layers), as opposed to a workspace reusing and repassing the bigger workspaces containing the whole cache (bigger initial cache extract, then compressing and saving it to be passed as a workspace layer that is then downloaded, extracted, building on top, compressing and saving which then passed as a workspace cache to the next layer depending on it).
And finally, the caching system (save_cache, restore_cache) is based on a CircleCI environment variable named CACHE_VERSION which is appended at the end of the checkum fingerprint of a named cache. It can at any moment be changed to wipe actually used cache, if for some reason it is broken.
Consequently:
CircleCI cache should include packages cache (so that packages are downloaded and verified only once.)
Heads Makefile only downloads, checks and extracts packages and then patch extracted directory content if packages/.module-version_verify doesn't exist. This was missing, causing coreboot tarballs to be redownloaded (not present under packages) and reextracted and repatched (since _verify file was not present under packages/*_verify)
|
||
|---|---|---|
| .circleci | ||
| bin | ||
| blobs | ||
| boards | ||
| build | ||
| config | ||
| initrd | ||
| install | ||
| modules | ||
| packages | ||
| patches | ||
| .gitignore | ||
| .gitlab-ci.yml.deprecated | ||
| COPYING | ||
| FAQ.md | ||
| Makefile | ||
| README.md | ||
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
initrdimage. - 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.