#cheriot — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #cheriot, aggregated by home.social.
-
If you want to understand how CHERI works and the relationship between memory safety and compartmentalisation, and why starting from a programmer model is essential if you want to build useful hardware, here you go!
-
CHERIoT: Wie Microsoft und Cambridge Embedded-Systeme endlich speichersicher machen wollen ― Martin Rings
https://martinrings.de/elektronik/cheriot-platform/
"Die Zahl vernetzter Embedded-Systeme wächst rasant. Vom Smart-Home-Gerät über industrielle Steuerungen bis hin zu autonomen Fahrzeugen laufen heute Milliarden Geräte dauerhaft mit dem Internet verbunden. Gleichzeitig basiert ein großer Teil dieser Systeme noch immer auf klassischem C- oder C++-Code – und damit auf einer Technologie, die seit Jahrzehnten für Sicherheitsprobleme wie Buffer Overflows, Use-after-Free-Fehler oder Speicherkorruption bekannt ist. …"
2026-05-14
-
We're going to be hiring someone to work on CHERIoT software things soon. Full remote, but UK Only (for various funding purposes, we need more people in the UK). Happy to talk to junior people who have some C/C++/Rust experience. You'll initially be mostly writing C++, though we expect this to move to more Rust over the next year or so.
Some of the job will be driver development gruntwork (here is a datasheet, here is a software interface for this device class, please write a driver for the device that exposes the interface), some will be at a higher level of the stack (so, how do you design a secure, compartmentalised {something} stack?).
If these sound interesting, let me know!
EDIT: The hiring manager is going to be out for the next couple of weeks, so I'll probably be a bit slow to set up interviews / respond. If you see this in a week or two, don't assume you're too late!
-
Follow-on work is ongoing, focused on #CHERIoT.
-
It’s almost two years since I wrote about setting up CHERIoT so I wasn’t a BFDL, but is somehow seems topical again, for some reason.
-
I wrote this post over a year ago, but it probably needs repeating periodically. From my perspective, CHERI isn't really about security, it's about making it possible to solve a bunch of interesting language-interoperability and end-user-programming problems that happen to need a bunch of security fixed as building blocks. And so we get a load of security stuff for free. But that's not why I worked on it.
-
One of the things that was drummed into my head repeatedly working with the late Ross Anderson was that most security problems are usability problems. It doesn't matter how secure your cryptosysetm is if people send unencrypted messages because they can't understand how to do key exchange. It doesn't matter how secure and fine-grained your sandboxing is if it has a user-prompted privilege elevation mechanism and users are trained to just hit 'approve' every time a dialog pops up.
This is why #CHERIoT focused so heavily on building a usable programmer model from the start. Compartments communicate with other compartments by calling functions. Compartments share objects by passing pointers to them. Compartments have a mechanism to expose type-safe opaque types and that's surfaced directly in the source languages. There is no look-aside policy that you have to read to know whether a compartment exercises some right: it's all explicit in the source code.
WebAssembly makes it easy to do the same kind of isolation, but not the sharing. A C pointer in WebAssembly is a 32-bit offset into a memory. If you want an object that's shared between two WebAssembly sandboxes, that's a totally different kind of pointer. Early CHERI work tried this and we gave up because the cognitive load and porting effort of having two kinds of pointer was too painful.
-
When we originally created #CHERIoT, we added an instruction to make accessing globals uniform with respect to the rest of RISC-V. We fairly quickly realised it wasn’t a great design, but the toolchain changes required to eliminate it took a while.
We’ve finally done it and I spent a bit of time this week writing up our journey. Removing this instruction is something we always planned to do before rebasing on the upcoming RV32YE base.
-
We’ll be talking more about the progress on the CHERIoT port of Rust at CHERI Blossoms next week, but here’s a teaser:
The embedded graphics crate rendering an image on Sonata. This currently using a (memory-safe) C function to draw pixels (that can go away with a little bit more work) but the current compiler is able to build this crate and run it in a CHERIoT compartment.
-
Me? Trolling the other microcontroller vendors? Surely not! Maybe if they had bothered to do something about the most common source of vulnerabilities at some point in the last few decades, the could have been on the other side of the sign...
-
Yay, we won a Best in Show Award at #EmbeddedWorld ! In the Microcontrollers, Microprocessors, and IP category for our ICENI #CHERIoT chips!
-
First Post! Uh, I mean, First CHERIoT Silicon!
We have our first chips back! It is very exciting! Spatial and temporal memory safety, fine-grained compartmentalisation, and also a load of other big chips on a board, so you can play 'Where's ICENI?' on the board picture!
-
This probably deserves its own post:
We've just open sourced a tool that Tim Hutt wrote for #debugging #CHERIoT things. The tool consumes a CPU trace from CHERIoT Ibex and exposes a gdbserver protocol interface. You can then use CHERIoT lldb to step forwards and backwards in your trace.
-
@cheri_alliance has posted about the Secure Horizons event in Duxford next week, which will be a great event for people who want to understand how CHERI (and, especially, CHERIoT) can make regulator compliance easier for secure IoT devices (as well as actually making them more secure).
Registration is still open and some SCI folks will be there!
-
Shout out to the folks maintaining the pq-code-package repos. I’ve been building their ML-KEM and ML-DSA implementations for CHERIooT and they’ve been an absolute delight to work with. I don’t think I’ve ever had better interactions with a F/OSS project (though I have had a few that were as good).
Don’t worry, I’m not touching any of the crypto code…
-
Mostly when I talk about #CHERIoT, I'm talking about the security, because that's the biggest and most obvious feature.
But since I've ranted a bit recently about Free Software things that don't empower users, I wanted to take a minute to write about how CHERIoT RTOS and is built on the principles that I think can provide maintainable systems.
The CHERIoT software is designed around compartments, which are somewhat like MULTICS shared libraries. They are isolated things that can own some mutable state and expose entry points, which are functions. Code in one compartment can invoke code in another compartment by simply calling a function that the other compartment exposes. This is a security domain transition. The callee has access to objects that were passed by reference, but there is no implicit sharing (and the hardware lets you share read-only view of data structures, or share for the duration of the call, and so on).
This model means that a lot of things that you run on the platform are tiny. This include the RTOS itself. There are four core bits of the RTOS:
- The switcher, which is the equivalent of the kernel, and is around 350 instructions. This is the most privileged part of the system and implements the fundamental bits of the programming model that are too complex to put in hardware. It is carefully co-designed with the hardware architecture though, and we expect very few users will ever modify it. We're working to formally verify it.
- The scheduler is trusted for availability, but not for confidentiality and integrity. It is just another compartment. We provide a simple fixed-priority scheduler with priority inheriting futexes. We think it's a nice design for embedded systems, but if you want to build your own scheduler you really just need to implement the function that the switcher calls that says 'this is the thread that was interrupted, go and talk to the interrupt controller and figure out which new thread you want to run now' and the futex APIs.
- The heap allocator. This owns the region of memory used for the heap and works with the hardware to enforce spatial and temporal safety. We provide an implementation of this in C++, some folks at UBC are working on a reimplementation in Rust using Verus. If this is slower / bigger, we'll support both, if it's as good then we'll probably replace ours.
The RTOS also contains a bunch of optional shared libraries and makes it easy to wrap other components. For example, we have a network stack that puts BearSSL, the FreeRTOS TCP/IP stack, and the FreeRTOS MQTT libraries in compartments and adds a control-plane compartment that manages authorisation for socket creation and firewall control, a firewall compartment, and a DNS resolver compartment.
Most of these are small. If you want to replace BearSSL with WolfSSL or something similar, that should be easy. If you don't want to use it at all, that's fine too, you can replace the entire network stack with something different if you want to.
The goal is to have a load of building blocks that device vendors and end users can easily reuse if they want to, but that they can easily replace with their own things if they don't like ours.
We built an auditing framework that makes it easy to add CI-time or code-signing-time checks to enforce rules like 'only the firewall can talk to the network interface device directly' or 'only the TLS compartment may call the TCP send and receive functions'. We did this to support the conflicting requirements of proposed right-to-repair legislation (which should give end users the right to modify the software on their device) and other safety regulations (which may restrict the ability to modify things like the code talking to software-defined radio, or the safety-critical parts of a medical device). This enables people who build on the platform to create devices that empower their end users, even in domains where allowing replacement of the firmware may be illegal.
-
Mitre has just published their top 25 most dangerous software vulnerabilities of 2025
How does #CHERIoT stack up against this list?
5, 7, 8, 11, 14, and 16 are deterministically mitigated with just a recompile.
13 will trap, but is recoverable on a per-compartment basis.
15 is trivial to mitigate with compartmentalisation. Phil Day wrote about this 18 months ago.
6 is mitigated by good capability-based filesystem APIs.
25 is mitigated by our software capability model in the RTOS.
1, 2, 3, 9, 10, 12, 22, and 23 and are not normally applicable on embedded platforms.
That leaves you with a lot more spare brainpower to think about avoiding the remaining seven (4, 17, 18, 19, 20, 21, and 24). The impact of many of these is limited in an environment where there is a programmer model that makes implementing the principles of least privilege and intentional use trivial.
-
I got ML-KEM and ML-DSA running on CHERIoT! The are faster than I expected!
TL;DR: You probably don't need PQC hardware for a CHERIoT device unless attackers with physical access are part of your threat model.
-
Anyone at #BlackHatEurope today, if you are tired of all of the AI nonsense and want to talk about #CHERIoT, we are in the business hall in the corner next to Theatre A. Come and say hello!
-
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!
-
It’s interesting that the CrowdStrike and CloudFlare issues could both have been solved in the same way by applying quite old best practices for engineering resilient systems. Both involved a crash in applying an update. Both failed to handle a specific error case, but outside a small niche of very critical systems you should never assume that you have handled every error locally.
Both could have been avoided by sandboxing the parser code, separating it from the code that fetched the updates and, if applying the latest update failed a few times, reporting an error to the server and continuing with the last update that didn’t crash the parser.
This is the kind of system we make it trivial to build with #CHERIoT, which is why I think it is the best option for anything that wants to ship products that last for decades with a security update every few years.
-
For anyone who missed CHERITech, there’s an online after party on the 4th! The talks will be online shortly and then CHERITech Reloaded will give you an opportunity to ask questions.
So you have two weeks to think of awkward questions for me about CHERIoT Audit! Good luck!
-
Yay, the embargo was finally lifted yesterday so we can talk about the UK Government funding for #CHERIoT!
They funded us (SCI) to do two projects, for a total of £7.7M:
- Bring #Rust on CHERIoT to production qualities.
- Build our second-generation chip with a dual-issue core, post-quantum crypto hardware, and an edge inference accelerator.
-
One think has really struck me in most pictures of #RTOS designs that I’ve seen recently: they all have a HAL or device driver layer at the bottom. The bottom layer is your trusted computing base (TCB): the bits that have to be correct for any of your security guarantees to hold. But device drivers talk to the outside world. Ethernet, SPI, I2C, UARTs, and so on are all parts of your attack surface: the place where an attacker is most likely to start attacking your system.
By combining your external attack surface with your TCB, you guarantee that an attacker who mounts a successful exploit has complete control over the system.
This is why #CHERIoT RTOS makes it trivial to delegate devices to the least-trusted portion of a firmware image. A compartment with exclusive access to a device doesn’t get any privileges other than a CHERI capability (hardware-enforced pointer) authorising access to that device’s MMIO region. If an attacker compromises it, they get access to that device, and maybe a way of trying to attack the next compartment, but it’s just the first step towards device compromise, not the end. Device drivers for single-user devices are just a software engineering abstraction, not a security boundary: they let you avoid thinking about device-specific details. Device drivers that handle multiplexing have no special privileges other than access to the device. At worst, compromising one allows you to break the isolation that the multiplexing provided.
-
We have released 1.0 of the #CHERIoT specification! The architecture has been unchanged for almost a year and has been implemented in two open-source cores. We (SCI) are getting back our first CHERIoT silicon from the fab soon and will be moving to mass production net year (I can't talk about what other people are doing with CHERIoT).
-
Great to see so many OS folks at SOSP last week when we presented the CHERIoT RTOS paper (and not to be the only one presenting work on CHERI)!
The paper is now live in the ACM Digital Library and already has almost 2,000 downloads. Hopefully a few of those will even translate to people reading it!
-
#CHERIoT by @david_chisnall in the latest FreeBSD Journal: https://freebsdfoundation.org/wp-content/uploads/2025/10/chisnall-cheriot.pdf