R&D: TrustZone

[nickray]

Background: With @solokeys, we're working towards replacing C with Rust, based on RTFM, and would like to take advantage of TrustZone to enhance security. We'd love to be one of the first commercial products demonstrating all the promise open source, Rust and RTFM have.

I do understand the current focus of RTFM is on supporting multi-core, I am not aware of the rest of the current roadmap (besides @korken89 telling me there is no current effort, and asking me to formulate this in an issue). I'm also still pretty much an RTFM noob, despite the nice workshop :)

May I suggest as next major R&D adding support for Cortex-M TrustZone? In a way, this can be considered a variation on multi-core: some resources are doubled, others are configurably split between "secure" and "non-secure" operation. Given RTFM's position as owner of all the things, it would naturally take on the responsibility of configuring and organizing these splits.

To give a concrete use case: For our security keys, I would like to both keep secret key material (for signatures/decryption) in a secure flash partition managed by littleFS, and have associated cryptographic operations implemented in secure mode, with "apps" (like FIDO2/OpenPGP/PIV/WireGuard/crazy-cryptocurrency-stuff/experimental that multiplex against dispatched USB requests) using the SG instruction as a kind of system call. In this way, a rogue application might be able to perform unauthorized operations, but not extract secret material (or at least, there would be more layers of security to pierce). I am not currently thinking of a general "plug-in" model with completely untrusted "apps", but rather simple things like USB glitching or other external attacks, that make a tested/trusted app go rogue: a SecureFault should stop this.

Current practice for this kind of things is using two chips, one general purpose microcontroller, and one "secure" element which is closed source and locked behind NDAs. My motivation is to replace this kind of obscurity with an open model -- in the future, Cortex-M35P might add the physical tamper-resistance to complete the picture. </lengthy use case excursion>

Of course, this kind of secured/trusted computing tends to get broken eventually (for instance the SAML11 Cortex-M23 seems to be fundamentally broken), but I still hope you're enticed by the prospect of doing multi-core with just one chip :) Or to put it more academically, coming up with the right abstractions to operate TrustZone. On the C side, I'm not aware of much beyond bloated frameworks and the incomplete LTZVisor.

On the Arm side, @hug-dev has been doing some work on implementing the Security Extensions as Rust attributes in an unpublished trust crate; I understand this is currently blocked on upstreaming those in LLVM.

If this is tackled, I'd suggest using the LPCXpresso55S69 board to implement against. FYI, I'm currently working on a basic HAL which runs in non-secure mode ("as if" there were no TrustZone), and you'll be aware of lpcxpresso55S69.

Thoughts?