Orthrus

I've figured out how to make use of the tightly coupled memory (TCM) on the SAMS70. The TCM comes in two chunks - ITCM for code and DTCM for data. Configuring TCM results in a reduction in the amount of SRAM available. I've compromised and configured 64K each of ITCM and DTCM, which results in 128K of SRAM.

I'm using the ITCM for some of the hot-spot code centered around the cryptography. That makes a little less impact, however, due to the fact that I previously was able to enable the ICache (enabling the DCache isn't quite so easy, as you have to sprinkle cache invalidation calls throughout your code to get away with it). I've moved the stack, the main disk block buffer and a few other crypto-related data structures into DTCM. I tried to move everything there, but that hasn't worked. Still, even with just that much (and with -O3), the throughput for sequential reads is North of 1.3 MB/sec.

I've also managed to extract the chip's unique ID and turned that into a USB serial string. It shouldn't really matter, but you can use that to tell two Orthrus' apart (or make sure that your Orthrus hasn't had its controller swapped out without being noticed).

My friends at SteamyTech are going to be designing and making the cases for Orthrus. The first prototype wasn't perfect because the board and its components were thicker than the acrylic used to make the layers. The result of that was that two layers would have been required between the top and bottom. I've ordered new PCBs with 0.8mm thickness instead of 1.6mm, and with that the height of the board and its components (except the button) should fit in 1/8". I'm sourcing some 1/16" acrylic rods from Amazon to hold a piece in place between the two SD card slots. Lastly, I'm going to see if Olander has some 4-40 threaded flanged inserts that can be used instead of bolts.

I've gotten some samples of security seals. Recall that the entire point of putting Orthrus in a case is to keep adversaries away from the ERASE header (make no mistake - even if I didn't populate an ERASE header, the chip still has the pin, and it's well documented). With Orthrus in its case, as long as you know that no one has opened it, and if the firmware was programmed with the security bit on, the chances are quite slim that anyone would be able to install rogue firmware.  The seals I've chosen are FIPS 140-2 certified holographic serialized seals. As long as you keep a record of the serial numbers sealing your Orthrus and see that they don't change without your knowledge, you should be able to trust the firmware. To insure that the firmware isn't tampered with in transit, orders for Orthrus that include the case will have the serial numbers on the seals communicated separately so that the buyer can confirm they haven't changed in the mail.

There are some small gaps that could conceivably be used to fish a small wire into the case, but I think it would require Mission: Impossible levels of effort to be able to successfully access the ERASE header without breaking a case seal.

I will be selling replacement seals in pairs for a nominal charge on the Tindie store to facilitate re-sealing Orthrus after field firmware updates.

This is about as secure a system as I can design. If anyone has suggestions for things I've missed that can improve things, I'd love to hear about them.

In order to further protect against rogue firmware, I've created a firmware signing certificate and used it to sign the firmware in the release zip. There's also a README included with the steps to validate the signature. It's simple operations with OpenSSL. The code signing certificate is also separately included in the Files section of the project and has been checked into GitHub, but if you're really paranoid then you should contact me offline somehow and I can provide you with the expected SHA256 hash of the certificate or some other reasonable proof of authenticity.

If it turns out there is some reasonable and free mechanism for obtaining a trusted code signing certificate, I'll endeavor to resign the same public key, if possible.

Meanwhile, this will allow for reasonable security around field firmware updates.

The first version of the firmware is now really complete. There were a couple of bugs discovered since the last time I said that:

• all calls to msc_xfer_blocks() results in a callback to the xfer_done() method, including the call after a write with block count 0 to mark the write commit.
• In Atmel Start's world, you're not allowed to have side effects in ASSERT(), as it is optimized to a null statement in release builds. So "ASSERT(NO_ERROR == perform_action());" doesn't call perform_action() in release builds. You have to assign the result to a variable and ASSERT the variable value instead.

With that, the raw block read speed of Orthrus is something like 1.25 MB/sec and the write speed is just over 300 kB/sec. So the goal was achieved. But there's hope that with a little bit more work to turn on the DCache and perhaps even move to TCM that this might improve even more. We'll see.

As previously discussed, for maximum security, the goal will be to encase the Orthrus board in a tamper-evident sealed case to keep miscreants away from the ERASE pins. The idea is that as long as the case remains sealed (and the seals are serialized, so you can be sure they haven't been replaced), you have some level of trust that the firmware hasn't been tampered with.

This means that there are four things open to an attacker to monkey around with: the button, the two SD card slots and the USB connection.

The button, SD card slots and the USB data bus all fall under the purview of the firmware, so it's on me to make sure that there aren't any bugs there. I make no sacrosanct promises, but I'm going to do my best to squish anything I find, either in my code or ASF4.

What's left is the power supply. Since it's potentially under the control of an attacker, that makes the system potentially vulnerable to power games.

Make the voltage too high and you'll likely destroy something. That isn't really a security vulnerability, per se.

But when the voltage of a microcontroller goes too low, stuff starts to just go wonky in ways that are unpredictable. It's a crude attack, but it's been shown in the past to bear fruit.

The defense is an UVLO circuit. If the voltage on the (nominally) 3.3 volt bus drops lower than 3 volts, the supervisor will pull the NRST line to ground, which will hold the chip in reset. If the voltage goes above the threshold, it holds the chip in reset for an extra 20 ms before releasing it.

The MIC803 is just the ticket. It's output is an open-drain, so it won't interfere with NRST being driven by the JTAG/SWD port, and there's already a 100 kΩ pull-up on that line.

This will be added to the next set of boards built, but it won't be on the first boards that ship (or the boards for the HP judges).

Turning on the ICache brings performance up to around 875 KB/sec. Unfortunately, turning on either DCache or ITCM causes USB to break. Probably cache coherency issues or something like that. I'll look into it. TCM would likely be a huge boost for the system if it could be made to work.

The firmware is now feature-complete and ready for use. I've uploaded a release build of the firmware. You can build your own hardware and use micro-samba to load it as described in an earlier log.

This firmware build assumes a 12 MHz crystal. I'll be using those exclusively going forward, as they allow maxing out the CPU frequency. That said, 16 MHz will also work if that's what you've got handy. Be sure to adjust the .atstart accordingly.

The release build running at 300 MHz benchmarks at around 750 kB/sec. Short of the goal, but close, and much better than v2.

I got Orthrus v3 hardware working all the way as a disk drive last night. There are a few bugs in Start's code that you have to work around:

• Start doesn't adjust the UTMI_CKTRIM register when configured with a 16 MHx crystal. You have to do that yourself.
• mscdf.c has no support for the MODE_SENSE_6 command, which is necessary (you just have to give back 4 zero bytes).
• mscdf.c has a bug where it returns non-zero when there's no error sending the zero-length "sync" at the end of a write.
• Start doesn't allow you to configure 512 byte endpoints, as the HS spec requires.

There are still a couple of bugs to work out - mostly centered around the handling of situations where cards are removed or missing.

Performance is not as good as hoped. Throughput is around 540 MB/sec. Halving the SD card clock doesn't appreciably change throughput, so this may be being limited by USB. But even at only ~5 times faster than before, it's now actually usable as opposed to unacceptable.

Another couple of days to polish the firmware, and I think I'll be able to send some units off to the HP judges!

We're now at the point where USB attempts to start doing block I/O, but that's not working.

I've checked in my progress so far. To use it, grab the .atstart and open it in Atmel Start. Save the result as an Atmel Studio 7 project, then open it in Atmel Studio.

Next, add the bizarro workaround to the start of ResetHandler() in the startup code.

Now you have to change the CONF_USB_MSC_BULKIN_MAXPKSZ and CONF_USB_MSC_BULKOUT_MAXPKSZ constants from 0x40 to 0x200. They're located in usb_msc_config.h under Config.

Lastly, copy the .c and .h files into your project, overwriting any that may have been put there by Atmel Start. Don't forget to add them all to the project.

Rebuild the project and you're good to go.

If anyone can figure out what I'm doing wrong with the I/O transfer code, let me know.

It turns out that if you swap out the 16 MHz crystal for a 12 MHz one, USB seems to work a lot better. The firmware hasn't completed the full attach sequence just yet, but it's much further along.

It's unclear why 16 MHz doesn't work. The datasheet says both are acceptable, and both work with SAM-BA in ROM. But Atmel Start doesn't have any knob I can find that you need to flip for the UPLLCK when it's coming from a 16 MHz source, and there's nothing in the datasheet about that either.

12 MHz is arguably a better choice anyway, since it's 300 divided by 25, which means that the CPU clock speed can be maxed out (I was using 288 MHz before).

Another bug in Atmel Start is that it won't allow you to set a bulk endpoint maximum packet length of higher than 64. The hardware supports up to 1024, and the high-speed spec requires a minimum of 512 (alas, that change isn't enough to fix the enumeration problems).

So... that's progress, at least.

I've updated the schematic / board files, making v3.0.1. The 3.0 boards are still fine - nothing much changed on the board. I've added a 0 Ω resistor as a disconnect point for Vddcore so you can experimentally disconnect it if you're so inclined (the resistor pads have a trace jumping them so there's no need for an actual part). There'a also an ever-so-slight tweak to the USB line layouts, but it's not so significant as to make much of a difference (beyond being more theoretically correct). High speed differential signals like that should not have "T" paths, and I made a small pair to connect the TVS protection diode matrix. Now the traces enter and exit the pads, meaning they stay more linear.

Version 3.0 is still what's going to be submitted to the judges for the HP. I just need to get USB working the rest of the way...