#cheriot — Public Fediverse posts

Yay, we won a Best in Show Award at #EmbeddedWorld ! In the Microcontrollers, Microprocessors, and IP category for our ICENI #CHERIoT chips!

#CHERI

We (SCI Semiconductor) are about to hire some folks in the next couple of months (probably starting in January, since we're about to hit Christmas):

We're aiming to hire 1-3 FAEs, who can build out the open-source bits of the #CHERIoT software stack (including drivers / various communication stacks), build demos, and work with customers on use-case bringup.

We also want to hire someone else on the toolchain side. Primarily #LLDB + #OpenOCD, but also working with our #LLVM (and #RustC) folks.

Let me know if you're interested!

EDIT: We are a full-remote company. It's easiest for us to hire people in the UK (and one of our investors would really like us to hire more people in Sheffield), but elsewhere is possible (though might, for tax purposes, require you to be officially a contractor for a while).

We're also going to be hiring people for our hardware verification and RTL teams soon (more on the verification side than design at the moment, I think). I'm not responsible for them, but I can find out more details if anyone is interested. Our first CHERIoT chip is nearly finished, we're starting to work on the second.

EDIT 2: Thanks to all of the people who have expressed interest (in public and private posts). I'll try to get back to you all next week!

EDIT 3: I hope I've replied to everyone now! If I missed you (there were more replies than I expected!) please let me know. I think we'll aim to do another hiring round over the summer next year, so if the current timeline doesn't work out for you, please still let me know and I'll keep you in mind next time!

#GetFediHired

Do you want to see #CHERIoT talking to #Morello, showing big server and tiny IoT-class #CHERI systems from the #DSbD ecosystem? Come to the UKRI stand at CyberUK this week!

Okay, I lied slightly on Monday. That wasn't the world's most overengineered light switch. How can you make it more over-engineered? By adding a JavaScript interpreter!

In this version, the #CHERIoT system is connecting to the MQTT broker (still running on a #Morello) and downloading some JavaScript bytecode. An instance of a JavaScript interpreter then runs in a separate compartment, where it can subscribe to MQTT topics, publish on those topics, read the status of the buttons and switches, and control the LEDs.

This brings the total up to 10 compartments (on a device with 256 KiB of RAM), with full spatial and temporal memory safety. In the case of the JavaScript code, with a copying garbage collector. This composes well with the lower-level CHERI memory safety. When a pointer is passed from JavaScript to C/C++, the JavaScript interpreter sets bounds. The JavaScript heap is composed of regions where objects are stable. During a collection, objects are moved to a new allocation and the old blocks are freed. If C/C++ code holds a dangling pointer then it remains valid until the next GC pass and is then invalidated by the underlying CHERIoT temporal safety mechanisms.

Would real IoT devices use JavaScript to control light switches? Maybe not (though you never know), but it demonstrates how flexible the CHERIoT platform is.

We didn't have to modify Microvium to run in a CHERIoT compartment but we did upstream a few (very small!) things to them apply bounds and to allow Microvium to run as a shared library. This means that, if you've got a compartment using JavaScript, you can add another with a tiny memory overhead (on the order of 1-2 KiBs, depending on the amount of JavaScript).

Oh, and although JavaScript is type safe, we don't rely on that for isolation. The JavaScript compartment has access to a very small attack surface and so even bugs in the JavaScript interpreter don't give very much power to an attacker. This means that you can allow device owners to provide their own JavaScript if they want to (with some small extra validation of the messages that they send), without compromising the security of your back-end service.

@alilleybrinker It's interesting to see the evolution of attacks. It's worth noting that the higher percentage of non-memory-safety bugs in some aspects of the corpus is because everything in those domains is written in memory-safe languages. Web APIs in PHP, JavaScript, Python, Ruby, and so on are not going to see memory safety bugs.

Memory safety bugs are particularly bad because they step outside of the abstract machine and so are more likely than anything else to lead to arbitrary code execution.

I'm also somewhat amused by Herb's claim that C++ can reach 98% memory safety: On #Morello and #CHERIoT, we've been running 100% memory-safe C++ for years! The improvements that Herb's proposing are important for availability, but we already prevent memory-safety bugs from being confidentiality and integrity violations. We also enforce those same properties even in things that are out of scope for the C++ standard, such as inline assembly.

The growth of the other bug classes is why I say that I don't care about memory safety except as a building block for higher-level abstractions. It's a useful baseline, but language-level enforcement isn't sufficient because your TCB code (the highest-value target for attackers) always needs to step outside of language-level safety to implement those abstractions. We couldn't build things like the CHERIoT compartmentalised network stack and even if we did then we'd be bringing a few million lines of a compiler into our trusted computing base.