Secure Boot notes

[jonas-schievink]

I've looked into Secure Boot while working on the custom U-Boot build and persistent installation, so I'll post some notes from that here. Note that I haven't yet tried to perform a Secure Boot using either approach.

There are 2 ways to implement Secure Boot for the Armory:

• Do a high-assurance boot into U-Boot and have it check the firmware signature.

  This has the benefit of using an established first-stage loader, which reduces the risk of introducing our own bugs. It also provides some useful setup code that we need in order to run anything (like DDR initialization). The big downside is that it opens us up to security issues in U-Boot.

  This would be accomplished by teaching the runner to assemble the ELF into a U-Boot compatible archive by writing a device-tree spec and running U-Boot's mkimage tool (which in turn calls dtc to build the device tree, which is a Linux tool). A custom U-Boot would be built that includes the public key used for firmware signing.

  We'd basically follow these instructions, but adapt them for non-Linux usage.

• Do a high-assurance boot directly into the firmware.

  The benefit of this is that we'd only rely on the Boot ROM to be secure (which is probably also not true, but it's better than also pulling in U-Boot), and remove more moving parts.

  The downside of this approach is that we'd have to write more code for generating the right data structures expected by the Boot ROM. This is also harder to debug, and AFAICT there's no existing applications that make use of this (all Linux images seem to use U-Boot). We'd include the DDR setup code that's currently in the U-Boot patches here. This all seems to be documented in IMX6ULLRM.

  There are a few existing tools for setting this up: usbarmory_srktool and usbarmory_csftool. I also have some prior experience with working with firmware images that support secure boot since I wrote the gbl crate.

[tarcieri]

U-Boot seems to have enough high severity security vulnerabilities owing to memory (un)safety I think it's definitely worth investigating whether or not we can eliminate it:

https://www.cvedetails.com/vulnerability-list/vendor_id-18843/product_id-48033/Denx-U-boot.html

[abarisani]

In case it helps TamaGo now doesn't rely on U-Boot any longer:

https://github.com/f-secure-foundry/tamago-example/blob/master/Makefile#L90

We had to take care of initializing a few things that U-Boot did for us, but overall it was rather painless.