CHERIoT at the Digital Security by Design All Hands meeting

Several companies presented CHERIoT-related things at the Digital Security by Design all-hands meeting yesterday!

lowRISC, whose Sonata board was used by all of the demos, presented a demonstration of an automotive system where a bug in the volume control would overwrite the speed controller value (on a non-CHERI system). The source for this is in the Sonata software repo, as is the snake example that lowRISC also showed.

ConfiguredThings presented an extended version of the configuration management demonstration that they’ve previously contributed to the project. The updated version integrated the CHERIoT network stack to talk to their back-end secure configuration management system. The code for the original version of their demo is open and the network-connected version should appear in the same place soon.

This showed how a CHERIoT system can provide additional defence in depth. Each configuration block from the server was parsed in a separate compartment, so bugs in the JSON parsing are not exploitable. The worst that can happen is that an invalid configuration update is ignored. CrowdStrike provided a good demonstration of how bad this can be without CHERI.

Finally, we at SCI Semiconductor presented a demonstration of the network-stack restart work that we released over the summer. This ran on Sonata, but (as with the other demonstrators) will be trivial to port to our ICENI CHERIoT chips, which are expected early next year. This showed a simple multi-colour light that was connected to the Internet via MQTT. The CHERIoT network stack runs the FreeRTOS TCP/IP stack (‘FreeRTOS+TCP’) in a compartment. We introduced a memory-safety bug into this code, which forms a key part of the attack surface (it’s the thing that has to process packets that come from the Internet, where all of the bad people live). When this is triggered, we see a CHERI exception on Sonata’s CHERI fault LEDs and the network connection is dropped. The TCP/IP compartment is then restarted automatically and the application code resumes:

The code for this demo is available. Note that there’s nothing in the application-specific part of the code related to the TCP/IP stack crashing. From the perspective of a consumer of the TCP/IP APIs, sockets just return a disconnection error. The normal reconnection paths then succeed once the TCP/IP stack has been restarted.