#CHERIoT

David Chisnall (*Now with 50% more sarcasm!*)Great to see so many OS folks at SOSP last week when <a href="https://cheriot.org/rtos/publication/2025/10/18/cheriot-at-sosp.html" rel="nofollow noopener" target="_blank">we presented the CHERIoT RTOS paper</a> (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!<a href="https://infosec.exchange/tags/CHERI" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERI</a> <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a>

Ed Maste<a href="https://mastodon.social/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a> by <a href="https://infosec.exchange/@david_chisnall" class="u-url mention" rel="nofollow noopener" target="_blank">@david_chisnall</a> in the latest FreeBSD Journal: <a href="https://freebsdfoundation.org/wp-content/uploads/2025/10/chisnall-cheriot.pdf" rel="nofollow noopener" translate="no" target="_blank">https://freebsdfoundation.org/wp-content/uploads/2025/10/chisnall-cheriot.pdf</a>

David Chisnall (*Now with 50% more sarcasm!*)RE: <a href="https://mastodon.social/@FreeBSDFoundation/115300447765010145" rel="nofollow noopener" translate="no" target="_blank">https://mastodon.social/@FreeBSDFoundation/115300447765010145</a>Oh, yay, I wrote one of these articles!<a href="https://infosec.exchange/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#FreeBSD</a> <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a> <a href="https://infosec.exchange/tags/CHERI" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERI</a>

David Chisnall (*Now with 50% more sarcasm!*)Anyone going to be at <a href="https://sigops.org/s/conferences/sosp/2025/index.html" rel="nofollow noopener" target="_blank">SOSP</a> in a couple of weeks? I will be giving a keynote at the <a href="https://kisv-workshop.github.io" rel="nofollow noopener" target="_blank">KISV workshop</a> on Monday morning about how CHERI changes how you think about OS design, and then we'll be presenting our paper on the CHERIoT RTOS first thing on Tuesday morning (and at the poster session).<a href="https://infosec.exchange/tags/SOSP" class="mention hashtag" rel="nofollow noopener" target="_blank">#SOSP</a> <a href="https://infosec.exchange/tags/KISV" class="mention hashtag" rel="nofollow noopener" target="_blank">#KISV</a> <a href="https://infosec.exchange/tags/CHERI" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERI</a> <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a>

David Chisnall (*Now with 50% more sarcasm!*)We’re looking at building a CTF competition to show off CHERIoT at Embedded World next year. We want to make it a supply-chain competition, so you get complete control over a source file that is compiled into the final image (including inline assembly) and have to exploit bugs in other compartments to control the device or leak a secret.Unfortunately, the last time we did a CHERI CTF (BlueHat a few years ago), we found it very hard to come up with bugs that were both exploitable and not so obviously stupid that there is no chance that they would pass code review. I think we can probably have some things at compartment boundaries that miss some checks for the permissions of capabilities passed at boundaries, but I’d welcome any other suggestions.(The last one was not a success because it wasn’t the only CTF running and everyone thought it was too hard, so we ended up with no one attempting it)<a href="https://infosec.exchange/tags/CTF" class="mention hashtag" rel="nofollow noopener" target="_blank">#CTF</a> <a href="https://infosec.exchange/tags/CHERI" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERI</a> <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a>

David Chisnall (*Now with 50% more sarcasm!*)<a href="https://mastodon.social/@fm_volker" class="u-url mention" rel="nofollow noopener" target="_blank">@fm_volker</a> <a href="https://bsky.brid.gy/r/https://bsky.app/profile/guillaumehiet.bsky.social" class="u-url mention" rel="nofollow noopener" target="_blank">@guillaumehiet.bsky.social</a> <a href="https://mstdn.io/@hle" class="u-url mention" rel="nofollow noopener" target="_blank">@hle</a> will be giving a talk about <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a> (based on our SOSP paper) there later in the year.

David Chisnall (*Now with 50% more sarcasm!*)For years, academic hiring and promotions (in computer science, at least) have focused on precisely one thing: number of first-author papers in top-tier venues.Focusing on the number of papers encourages people to publish the so-called minimum publishable unit: The smallest thing that stands a chance of being accepted. This discourages large research projects where you may take multiple years to reach something worthy of a top-tier venue. It also discourages high-risk projects (or, as they are more commonly called: research projects) because there’s a chance of not reaching a publishable unit at all.Focusing on first author publications discourages collaborations. If two people work on a project that leads to a paper, only one will get the first-author credit. If a large project needs ten people on it, you need to do ten publications per year for it to have the same return on investment as everyone doing small incremental projects.The net result of this is that even top-tier venues are saturated with small incremental projects. Academics bemoan this fact, but continue to provide the same incentives.In the <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a> project, we have tried, in a small way, to push back on this. We list authors in alphabetical order and we add an asterisk for people who deserve the conventional idea of ‘first author’ credit. Alphabetical order makes it clear that the author list is not sorted by contribution size (and such a total ordering does not exist when multiple authors made indispensable contributions in wildly different areas).I was incredibly disappointed with the PC Chairs at the <a href="https://infosec.exchange/tags/ACM" class="mention hashtag" rel="nofollow noopener" target="_blank">#ACM</a> conference for a recent accepted submission deciding to push back on this (in particular, on including the exact same words that we used in our MICRO paper). ACM should be actively trying to address these problems, not enabling editorial policies that perpetuate them. If I had understood that the venue had such a strong objection to crediting key contributors, I would not have submitted a paper there nor agreed to give a keynote at one of the associated workshops.I am in the fortunate position that paper credit no longer matters in my career. But that doesn’t mean that I am happy to perpetuate structural problems and it is very sad to see that so little thought is given to them by the organisations with the power to affect change.The one exception that I have seen, which deserves some recognition is the Research Excellence Framework (REF) which is used to rank UK universities and departments. This requires a small number of ‘outputs’ (not necessarily papers) by each department, scaled by the number of research staff but not directly coupled to the individuals. These outputs are ranked in a number of criteria, of which publication venue is only one. It is not perfect (you will hear UK academics complaining about the REF with increasing frequency over the next couple of years as we get closer to the deadline for submission in the next round), but at least it’s trying. Simply not actively trying to make the problem worse is a low bar that I would previously have expected any conference to clear.

David Chisnall (*Now with 50% more sarcasm!*)I just tried cloc on the <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a> RTOS repo. Over 1/3 of the non-blank lines in the RTOS are comments. On top of that, the book describing how to use it is aroudn 62,000 words (so around six words per line of code in the RTOS), not including example code.

David Chisnall (*Now with 50% more sarcasm!*)We’re <a href="https://discourse.llvm.org/t/rfc-upstream-target-support-for-cheri-enabled-architectures/87623" rel="nofollow noopener" target="_blank">starting to upstream CHERI support to LLVM!</a><a href="https://infosec.exchange/tags/CHERI" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERI</a> <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a> <a href="https://infosec.exchange/@cheri_alliance" class="u-url mention" rel="nofollow noopener" target="_blank">@cheri_alliance</a>

Dave WeinsteinSince I'm looking for new opportunities, are there any companies hiring for <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a> right now? If so, I'd love to have a chat and see if there is a match.

David Chisnall (*Now with 50% more sarcasm!*)Ooo, fun. All of the Linux tools that we ship in the <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a> dev container work in the Linuxulator on <a href="https://infosec.exchange/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#FreeBSD</a> with <a href="https://infosec.exchange/tags/Podman" class="mention hashtag" rel="nofollow noopener" target="_blank">#Podman</a> There appears to be a bug in the Podman with image tags that are multi-arch manifests if you specify <code>--os Linux</code>: it downloads the image and then fails to run it. If you specify the tag for the x86-64 version, it works fine.

tigerhiddenadamCompiled and tested cheriot-clang21 preview against Sail tonight.Very nice.Put a smile on my face. Owen is a legend.<a href="https://techhub.social/tags/CHERI" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERI</a> <a href="https://techhub.social/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a> <a href="https://infosec.exchange/@cheri_alliance" class="u-url mention" rel="nofollow noopener" target="_blank">@cheri_alliance</a>

David Chisnall (*Now with 50% more sarcasm!*)Excellent news yesterday, the <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a> RTOS paper was accepted at SOSP!Huge thanks to <a href="https://mstdn.io/@hle" class="u-url mention" rel="nofollow noopener" target="_blank">@hle</a>, who led on rewriting the rejected submission and made numerous improvements to the implementation.We now have CHERIoT papers in top architecture and OS venues, I guess security and networking are the next places to aim for!<a href="https://infosec.exchange/tags/CHERI" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERI</a>

David Chisnall (*Now with 50% more sarcasm!*)Since working on <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a>, I've been surprised at how many other potential security problems I can just ignore if I have temporal memory safety that works in the presence of malicious compartments. If I free an object, I guarantee that nothing else I care about will alias it. Another compartment may have kept a reference, but they either claimed it (and so it counts against their quota) or didn't (in which case its pointer stops working right now). A whole chunk of the TLS stack can be riddled with TOCTOU bugs and I don't care because the scoped delegation mechanism means that, once a receive call has returned from the TCP/IP stack, I know that the TCP/IP stack can't hold a pointer to it, so the only thing that can mutate the object is the TLS compartment (and it's not actively trying to attack itself), so as long as it doesn't check something in the packet and then mutate it, it's fine: nothing else can, not even untrusted assembly code in the TCP/IP stack. I guess it's not surprising that it's easier to build secure systems if the hardware and core platform give you a sensible set of core guarantees.<a href="https://infosec.exchange/tags/CHERI" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERI</a>

David Chisnall (*Now with 50% more sarcasm!*)Exciting to see the first <a href="https://infosec.exchange/tags/Rust" class="mention hashtag" rel="nofollow noopener" target="_blank">#Rust</a> code running on <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a>! Edoardo has rebased the Kent work on a newer rustc and added the CHERIoT bits so we can now add two integers together in Rust!Probably other things work too. The core library compiles, but not much of it is tested. Cross-compartment calls aren’t possible yet and the alloc crate needs implementing wrapping our shared heap (there’s also a fun project at UBC to replace our allocator with a formally verified one in Rust, but it’s not there yet and, of course, depends on Rust working).

David Chisnall (*Now with 50% more sarcasm!*)I realised my previous post about why we wrote a new RTOS for <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a> was light on details. The core reason is at the end of <a href="https://cheriot.org/rtos/philosophy/history/2025/07/04/why-new-rtos-2.html" rel="nofollow noopener" target="_blank">the new post</a>: We don't want to build a system that is secure, where people can then layer insecure things on top, we want to build the core that enables you to build secure systems. And that requires rethinking a lot of core OS abstractions with usability and security as core requirements. We can't do that by retrofitting CHERI to an existing system.

David Chisnall (*Now with 50% more sarcasm!*)Does anyone know if GitHub Code Spaces work in China (specifically, Shanghai)? We are hoping to use them for a <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a> tutorial at the RISC-V event in a few weeks.

David Chisnall (*Now with 50% more sarcasm!*)A few people have asked me recently questions along the lines of ‘how mature is <a href="https://infosec.exchange/tags/CHERI" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERI</a> as a technology?’ The analogy that I usually use is the 386’s memory management unit (MMU). This shipped 40 years ago, at a time when most desktops did not do memory protection, though larger systems usually did. Similarly, most systems today do not do object-granularity memory safety. The 386 shipped after the 286 had tried a very different model for the same goal and had failed to provide abstractions that were usable and performant. Similarly, things like Intel MPX have failed to provide the memory safety guarantees of CHERI and thins like Arm’s POE2 have failed to provide the kind of useable programmer model for fine-grained compartmentalisation model that CHERI enables, yet both technologies have shown that these are important problems to solve.The 386’s MMU had a bunch of features that you’d recognise today. Page tables were radix trees, for example, just as they are on a modern system. It wasn’t perfect, but it was enough for Linux and Windows NT to reach Bill Gates’ goal of ‘a computer on every desk’, at least in wealthy countries (and the cost of the MMU was not the blocker elsewhere). For over 20 years, operating systems were able to use it to provide useful abstractions with strong security properties.It was not perfect. Few people thought, in 1985, that PCs would run VMs because they barely had enough memory to run two programs, let alone two operating systems. But the design was able to evolve. It grew to support more than 4 GiB of physical memory with PAE, to support nested paging for virtualisation with VT-x, and so on. It made some mistakes (read permission implied execute, for example) but these were fixed in later systems that were able to provide programmers with the same abstractions.And this is why I’m excited about the progress towards the Y (CHERI) base architecture in RISC-V, and why I believe now is the right time for it. There’s a lot of CHERI that’s very stable. Most of the things from our 2015 paper are still there. A few newer things are also now well tested and useful. These are an excellent foundation for a base architecture that I’m confident we can standardise and that software and hardware vendors can support for at least the next 20 years. At the same time, in <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a> (and some other projects) we have a few extensions that we know are validated in software and very useful in some domains (in our case, for microcontrollers) but not as useful elsewhere. Some of the things we’ve done in CHERIoT would be terrible ideas in large out-of-order machines, but would be great to standardise as extensions because they are useful on microcontrollers, and some might be useful on some accelerators. It would be great if these could share toolchain bits.There are also some exciting research ideas. I’d be much less excited by CHERI if I thought we were finished. 40 years after MMUs became mainstream, people are still finding exciting new use cases for them and new ways to extend them to enable more software models and that’s what a new foundational piece of architecture should provide. I firmly believe CHERI has the same headroom. After Y is standardised, I expect to see decades more vendor and standard extensions that are doing things no one has thought of yet, but which would be impossible without CHERI as a foundation.

David Chisnall (*Now with 50% more sarcasm!*)Receiving the IEEE Symposium on Security and Privacy's Test of Time Award for our 2015 CHERI paper seemed like a good time to <a href="https://cheriot.org/cheri/history/2025/05/16/last-ten-years.html" rel="nofollow noopener" target="_blank">reflect on how #CHERI has evolved (and how it has remained the same) over the past decade</a>This mostly focuses on the road to <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a>, there's a lot more going on in the wider ecosystem.

David Chisnall (*Now with 50% more sarcasm!*)<a href="https://discuss.systems/@edwintorok" class="u-url mention" rel="nofollow noopener" target="_blank">@edwintorok</a> Yes, there are two ways of doing this:Have a private per-compartment allocator that is provisioned with a memory range and subdivides it. We’ve done that for some big compartment models, especially the colocated process (coprocess) model that is used to provide an easy migration path for things that already do process-based compartmentalisation.Have a shared allocator that runs in an isolated compartment. This is what we do on <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener" target="_blank">#CHERIoT</a>. Remember that everything (from assembly on up) has to follow the memory-safety rules. The allocator has a capability (pointer) to the entire heap (on big systems, a set of these for non-contiguous ranges, CHERIoT is for embedded systems where the heap isa contiguous block of SRAM). When you ask to allocate memory, it finds an unused region in the heap and then sets the bounds of a capability derived from the heap capability to span only this region, then returns it.This means that the caller has access to the allocated object, but no access to the heap metadata or any other objects. Pointers to allocator metadata are never reachable from outside of the allocator.The CHERIoT allocator uses a (software) capability model that’s built on top of the hardware one so you can allocate only if you pass a capability that authorises allocation. This capability is a sealed pointer to a quota, so you can limit the amount of memory that a CODEC can allocate and you can free all memory allocated from a specific quota to clean up if you need to reset the CODEC after finding a bug.See chapter 5, section 6 of the book for more detail on how that works.

Recent searches

Search options

Administered by:

Server stats: