From 891730d13b324fad916572a82f0bd610c5de9aad Mon Sep 17 00:00:00 2001 From: Rob Austein Date: Sun, 13 Sep 2020 23:06:24 +0000 Subject: Rename for conversion --- .../GitRepositories%2Freleng%2Falpha.trac | 139 +++++++++++++++++++++ 1 file changed, 139 insertions(+) create mode 100644 raw-wiki-dump/GitRepositories%2Freleng%2Falpha.trac (limited to 'raw-wiki-dump/GitRepositories%2Freleng%2Falpha.trac') diff --git a/raw-wiki-dump/GitRepositories%2Freleng%2Falpha.trac b/raw-wiki-dump/GitRepositories%2Freleng%2Falpha.trac new file mode 100644 index 0000000..55ad7f1 --- /dev/null +++ b/raw-wiki-dump/GitRepositories%2Freleng%2Falpha.trac @@ -0,0 +1,139 @@ +{{{ +#!htmlcomment + +This page is maintained automatically by a script. Don't modify this page by hand, +your changes will just be overwritten the next time the script runs. Talk to your +Friendly Neighborhood Repository Maintainer if you need to change something here. + +}}} + +{{{ +#!html +

releng/alpha

+ +

Release engineering stuff for Cryptech Alpha board and support software.

+ +

Overview

+ +

The Makefiles and scripts in this repository attempt to automate the +process of building packaged versions of the firmware and software for +the Cryptech Alpha board. At a high level, this consists of two main +phases:

+ +
    +

  1. Building a firmware package (Verilog and C code which runs on the +Alpha board itself, regardless the host system to which the Alpha +is connected); and

    2. +

  2. Building software packages (code which runs on the host to which +the Alpha is connected).

    3. +
+ +

Since the firmware is the same for any given version of the Cryptech +source code, and since the process of building the firmware binaries +is both time-consuming and involves tools like the XiLinx Verilog +synthesis toolkit and cross-compilers for multiple CPUs (the Alpha's +Cortex M4 ARM CPU and the Atmel AVR ATtiny828 MCU used to implement +the anti-tampering logic for the master key memory), we include a +signed tarball containing pre-built binaries for all the firmware as +part of the source tarball for the software packages.

+ +

You are of course free to build all of this for yourself, with or +without modification, the pre-built versions are just a convenience.

+ +

Source Tree

+ +

The source code itself, for both the firmware and the software, is in +the source/ directory, with names corresponding to the canonical names +of the relevant git repositories. At the time this document was +written, a few of the repositories in question had not yet been +promoted to their expected permanent homes in the core/ or sw/ trees, +but we expect this to be temporary. Regardless, directory names +within the source/ directory tree are intended to track the canonical +names of the git repositories, whatever they may be at any given time.

+ +

Firmware Build Process

+ +

The firmware build process consists of five main phases:

+ +
    +

  1. Building a "shadow" directory tree populated with symlinks back to +the source tree. This allows us to preserve binaries between +compilation runs where appropriate, without cluttering up the +source tree with various intermediate files which don't belong +there. In particular, this allows to skip the Verilog synthesis +stage when nothing there has changed, which makes the overall +build process run significantly faster.

    2. +

  2. Synthesizing the Verilog source code into a bitstream. This phase +generates a single bitstream file, suitable for loading into the +Alpha's FPGA chip.

    3. +

  3. Cross-compiling C code for the Alpha's ARM processor. This +produces two images: the bootloader, and the HSM firmware itself.

    4. +

  4. Cross compiling C code for the Alpha's AVR MCU. This produces a +single image, which runs the tamper-response controller.

    5. +

  5. Packaging all of the firmware created in the above steps into a +tarball, with some meta-data describing the package, including +SHA-2 digests of all of the firmware image files and a signature +over the entire meta-data block.

    6. +
+ +

The precise formats which show up in the firmware tarball are subject +to change. At the moment, they consist of:

+ + + +

The overall packaging for the firmware tarball is intentionally pretty +boring: tar, gzip, gpg, and JSON. The intent is that users be able to +use our firmware tarball even if the scripts we provide are unsuitable +for some reason.

+ +

The final result of the firmware build process is the firmware +tarball, which is written into the source/ tree for inclusion by the +software packaging phase.

+ +

Software Build Process

+ +

The software build process also consists of several phases, but is a +bit more open-ended than the firmware build process. Phases in the +current build process:

+ +
    +

  1. Building a source tarball and Debian source package (".dsc"). +The Debian and Ubuntu Linux distributions are our primary +development platforms, so we need to produce packages for them in +any case, and the process of producing a Debian-family source +package produces a source tarball as one of its outputs, so we get +that for free by doing this step first.

    2. +

  2. Running pbuilder to generate clean binary packages for the +"i386" and "amd64" architectures for Debian Jessie and Ubuntu +Xenial.

    3. +

  3. Loading all of the Debian and Ubuntu packages produced above into +the staging instances of a set of APT repositories.

    4. +

  4. Generation of a Homebrew formula and committing that formula to +the staging instance of a Homebrew "tap" (git repository), using the +tarball created during the Debian source package stage as the +source package. The Homebrew formula is source-only (no "bottled" +binary packages): creating binary packages would not be +particularly difficult (one osxcross instance per version of +OSX we want to support would do it), but Apple's Xcode SDK license +doesn't permit this unless we run our build farm on Apple +hardware.

    5. +

  5. Uploading changes from the staging repositories to our public +repositories.

    6. +
+ +

In theory, it would also be possible to produce Windows binaries using +the MinGW cross-compilation environment, but Windows is sufficiently +different from all other platforms that even minimal Windows support +would almost certainly require extensive source code changes, so we +have not put any serious thought into build issues for Windows.

+}}} + +[[RepositoryIndex(format=table,glob=releng/alpha)]] + +|| Clone `https://git.cryptech.is/releng/alpha.git` || -- cgit v1.2.3