Geen omschrijving

Rob Austein b6e384115a README.md nits 4 jaren geleden
.dockerignore 0820895f73 Parameterize and clean up, now that basic hack seems to work. 5 jaren geleden
.gitignore 0820895f73 Parameterize and clean up, now that basic hack seems to work. 5 jaren geleden
Builder 9eb4a87c93 sudo is sticky 5 jaren geleden
Dockerfile 6fdf53365a Need the stretch-backports version of debootstrap's database 5 jaren geleden
Makefile cd57b6fa76 Update to Stretch 5 jaren geleden
README.md b6e384115a README.md nits 4 jaren geleden
Ratinox 0820895f73 Parameterize and clean up, now that basic hack seems to work. 5 jaren geleden

README.md

Cryptech build environment under Docker

This is an attempt to Dockerize the Cryptech build environment.

The ten zillion Debian packages are tedious but straightforward. The tricky bit is the XiLinx toolchain:

  • You need to download the Xilinx ISE Design Suite distribution tarball.
  • You need to get a license key from XiLinx before you can use ISE.
  • You have to run GUI installation tools to install and configure it.

There's not much we can do about the first two, so we assume that you've obtained a tarball and a license key file, and that you've dropped them into this directory with the filenames we expect.

The third...is fun, in a demented sort of way.

The Xilinx tools are serious disk hogs: VMs for this need at least 30-40 GB of disk space. The build process for this Dockerized environment is even worse: 60GB appears to be just barely enough.

To get a license, go to http://www.xilinx.com/products/design-tools/ise-design-suite/ise-webpack.htm and click on the Licensing Solutions link. On the resulting page, expand the section "Obtain a license for Free or Evaluation product". To download the ISE Webpack, you should have created an account, so now you can go to the Licensing Site and use that account to create a Certificate Based License.

You do not need to go through the HostID dance, just say "Do It". You will then receive a certificate in email (not an X.509 certificate) which you will be able to use.

Some URLs which might be useful:

Once you've downloaded the ISE installation tarball and the license file, you should place copies of them in this directory (the one with all the dockerization stuff). Since these were probably painful to obtain, you might want to store the files somewhere else (eg, the parent directory), chmod them 444, and hard link them into this directory.

After you've added those files to this directory, typing make should, in theory, build the whole thing. It takes a ridiculously long time to build, but we dont' expect this to happen often.

Legal caveat

Note that the resulting Docker image contains a licensed copy of the build environment, so passing it around to your friends or installing it on more machines than the license allows is a no-no. We're not attempting to circumvent XiLinx's licensing system, just make it possible to run builds which require ISE in a reproducable Dockerized environment.

Grotty details

Readers familiar with Docker wiil notice that this build environment is...kind of weird. Partly that's because of the size of some of the files involved, but mostly it's because the Xvfb/ratpoison hack we're using to drive ISE installation doesn't work under docker build. Don't know why, don't really care (so many windmills, so little time).

Current status

  • Building the bitstream and the HSM firmware works.

  • Building the fimrware tarball doesn't work yet, because releng/alpha/Makefile assumes it can use the releng PGP key. This will require a minor change to releng/alpha/Makefile and the supporting scripts, deferred until we figure out what other changes are needed for anyone other than the rleease engineer to use this.

  • Building the host-side source packages (tarball, .dsc, .rb) should work once firmware tarball problem solved.

  • Running pbuilder within Docker does not look practical. There are several Docker-friendly alternatives, eg whalebuilder, but nested Docker is a bad idea, so either we'd have to work out the socket hack for automated Docker-next-to-Docker or we'd leave building binary packages for the user. Not clear that ordinary user really wants us to spend the time building binary packages for every supported Debian and Ubuntu release anyway.

So we have some restructuring to do in releng/alpha/, probably with some automated conditional tests to see whether we have the releng PGP key, etc, with things rearranges so to make it easier for an ordinary user to run the dockerized stuff and further conditionals and make variables to let the user specify which binary packages to build (if any).