cryptech-build-docker

Docker

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 have to download the installation tarball by hand
• You have to get a license key from XiLinx before you can use it
• 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. Don't know whether it'll work yet, but going to try automating this using Xvfb, xautomation, and ratpoison.

XiLinx voodoo from Berlin workshop notes

• You need to download the Xilinx ISE Design Suite.

• Xilinx only supports specific versions of Red Hat and Suse Linux, but it does run on Ubuntu and Debian, with the following caveat: Ubuntu and Debian symlink /bin/sh to /bin/dash, which can't handle if [ ... ] syntax in shell scripts. Symlinking /bin/sh to /bin/bash works.

• The Xilinx tools are serious disk hogs: VMs for this need at least 30-40 GB of disk space.

Step-by-step installation (Dockerfile will attempt to automate this):

1. Unpack Xilinx_ISE_DS_Lin_14.7_1015_1.tar (or whatever version you have).
2. cd to Xilinx_ISE_DS_Lin_14.7_1015_1, and run sudo ./xsetup
3. Click through two screens of license agreements.
4. Select ISE WebPACK.
5. Unselect (or leave unselected) Install Cable Drivers.
6. Go!

Well, not quite. You will need to convince the ISE that you have a license.

On the page http://www.xilinx.com/products/design-tools/ise-design-suite/ise-webpack.htm 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. Then start the ISE Webpack by issuing the command ise. Go to the Help menu and Manage Licenses. Use the resulting new License Manager window to install the .lic file. This process is complex and flakey.

http://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/design-tools.html http://www.xilinx.com/products/design-tools/ise-design-suite/ise-webpack.htm http://www.armadeus.com/wiki/index.php?title=ISE_WebPack_installation_on_Linux

With the license file already present this is simple: follow the installation instructions, tell it to use existing license file, it'll find it if you click the right buttons. And yes, it's another GUI program.

The ise binary referred to above is in /opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/ise (or in .../lin/ise, but the pbuilder setup requires a 64-bit build machine).

It turns out you don't really need to run the whole ise tool to get to the license manager, you can just run the license manager directly, but you do have to source the appropriate settings file first, none of the XiLinx tools work properly without that. So:

. /opt/Xilinx/14.7/ISE_DS/settings64.sh
/opt/Xilinx/14.7/ISE_DS/common/bin/lin64/xlcm -manage

Kludges too awful to mention

The file finish.png is for the visgrep tool from the xautomation package. It sorta mostly kinda works as a mechanism for detecting that we've gotten to the end of the XiLinx installation process. I haven't gotten it to work quite as it says on the tin, but something like:

while true
do
    xwdtopnm 2>/dev/null framebuf/Xvfb_screen0 | pnmtopng >framebuf/screen.png
    if test -n "$(visgrep framebuf/screen.png finish.png finish.png)"
    then
        break
    fi
done

For reasons that I don't understand, visgrep returns failure (exit status 1) even when it finds the pattern, even though the manual says it's not supposed to do that. Dunno why. Ancient code. Whatever.

In practice, this is so nasty that I'm seriously tempted just to wait half an hour then blindly click on where the finish button should be.

Possible future direction

This whole thing is of course a kludge tower. Furthermore, due to the size of the installation files, normal Docker image layering would mean images at least 6GB larger than they need to be, so we're probably going to want to clean all that up then do a save | load cycle to squeeze out the garbage.

The whole Xvfb thing is pretty much impossible to debug under docker build, which is starting to look like a moot point in any case since Xvfb is refusing to start in that environment even when everything else claims to be right. So, an alternative plan: don't use a Dockerfile at all, just use docker import, docker run, and docker commit. Overall plan if we were to go this way:

1. Construct initial filessytem content using debootstrap -foreign (as we do now) and also untarring the XiLinx source tarball directly. Might as well drop in the handful of small scripts we'd otherwise have to COPY from a Dockerfile while we're at this.

2. docker import (as we do now, but with all the extra initial content too to create the stage1 image.

3. docker run the stage1 image with a bind mount for the Xvfb frame buffer directory, running an install.sh script we stuffed into the tree in step 1. This does apt-get to fetch packages we need, then does python install.py to run our Xvfb driver voodoo. install.sh probably needs to set -e so we can tell when something failed. Ideally, install.sh does everything including throwing away all the stuff we no longer need like the 6GB unpacked XiLinx installation tree.

4. Assuming that install.sh et al ran to happy completion, run docker commit to generat a new image from the result.

5. [Optional] docker save | docker load cycle to garbage collect, assuming that hack still works, whatever other hack (if any) to achieve same goal (gc).

One nice thing about this approach is that it lets us save screen images from the installation process, making this a lot easier to debug. Unless the internal scripts need it for some reason, we don't even need to convert from xwd format to something more common, we can just shutil.copyfile() the frame buffer file and leave the results for somebody else to deal with. If anything is going to keep those they should probably be converted to png but not critical.

OK, confirmed that the problem with running Xvfb is (somehow) specific to running under docker build. Same configuration (packge list, etc) ran (apparently) fine under docker run.

Attempting to docker commit the result blew out what was left of my disk space. Since we're going to want to clean up and collapse anyway, it's possible that docker container export is a better path than commit here: would have to feed the result to docker import to get an image, but that might be exactly what we want.