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. _______________________________________________ Tech mailing list Tech@cryptech.is https://lists.cryptech.is/listinfo/tech
