[Cryptech Tech] DFU of Alpha bootloader does not work

[Rob Austein]

Summary:

"Device Field Upgrade" (DFU) of the Alpha's bootloader bricks the
Alpha badly enough that one needs an ST-LINK to recover.

Background:

Because we knew there was still a lot of work to be done on the
Alpha's firmware, we split the Alpha's firmware into two separate
parts (well, three if one counts the FPGA bitstream, but for this
message I'm just talking about C code that runs on the ARM): the main
HSM firmware, and a separate bootloader.  The main firmware and the
bootloader can be upgraded separately, and in most cases there's no
need to upgrade the bootloader.  This is a fairly standard technique
for embedded devices, and while it's probably not something one would
want in a final HSM product, it's a good fit for development stage.

The upload mechanism itself is a bit kludgy, but does work for
upgrading the main firmware.  One runs a Python script which logs into
the bootloader and asks it to install the firmware upgrade into flash.
Upgrading the bootloader is supposed to work pretty much the same way,
using different options to the same Python script, but asking the main
firmware to upgrade the bootloader section of the flash.  Bottom line,
if one has a current APT or Homebrew package installed, one should be
able to upload a new bootloader just by doing:

  $ cryptech_upload --bootloader --simon-says

In practice, however, this does not work, and I'm not sure it ever
has.  Certainly I have never seen it work.  Instead, it bricks the
Alpha, so that one has to reflash the bootloader using an ST-LINK.

The odd thing is that the upload itself seems to complete, but the HSM
then hangs before the upload script can log out, and if one power
cycles it at this point (one has little choice) it never comes back.

To date I have not been able to figure out what's really going on
here.  In theory, one can run all of this under gdb via the ST-LINK,
but in practice things get weird pretty quickly on that path, not sure
why (threads? UART driver issues? Other timers? ...).  Somebody who
knows the Alpha's low-level code better than me might have more luck
here (hi Paul, hi Fredrik).

Why this matters:

It turns out that one situation in which one really does want to
upgrade the bootloader is when changing the format of the keystore,
because PINs are kept in the keystore, and one kind of wants the
bootloader and main firmware to agree on what the PINs are.  So the
ksng branch I've been working on really should use an upgraded
bootloader, thus this DFU problem with the bootloader makes it risky
for anybody to test the new keystore code without an ST-LINK.

Known bad workarounds:

1) Erase the keystore flash every time you want to upload a new
   firmware image: this causes both bootloader and main firmware to
   fall back to the last gasp default PIN, so things work as expected,
   at the small price of erasing all of one's keys on every upgrade.

2) Hack the upload script to prompt for two separate pins, one for the
   main firmware and one for the bootloader, then try to document
   which PIN the user should expect to have to use at which prompt for
   all the possible upgrade permutations.

I've spent enough time on this without making any real progress that
I'm going to turn my attention to other things for now.  If somebody
else could take a swing at fixing this, or at least understanding
what's really going on here, I would appreciate it.