For folks who missed my #KISV keynote or #CHERITech talk, I wanted to pull out the two key points.
The first is that CHERI solves memory safety, but that’s almost incidental. I don’t want to downplay addressing the root cause of 70% of vulnerabilities but that’s not the goal. CHERI was originally designed to support scalable fine-grained compartmentalisation. To do that well, you need a programmer model. You need to be able to share things programmers understand (objects, in object graphs) not pages. And that means you need to be able to trivially map your protection up to language-level constructs like pointers / references and protect both them and the objects that they refer to. And so you need to build memory safety. And, it turns out, making an entire program memory safe is much easier than making just an exposed API memory safe. So we have memory-safe C/C++ and we can use those from languages like Java or Rust to ensure that the C/C++ doesn’t violate the guarantees that the safe language’s security depends on. And then we can use that for easy to use compartmentalisation, safe FFI, supply-chain security, and many more things.
The second is that CHERI is still quite young. I gave a talk about how CHERI impacted OS design. That’s like, in 1985, asking someone from IBM to give a talk about how MMUs impacted OS design. They would tell you you could create VMs to consolidate multiple minicomputers onto a single mainframe. They would tell you that you could enforce process isolation. And, just like the things we can do with CHERI today, these are hugely valuable. But they wouldn’t tell you about using Zygote models to speed up process creation. They wouldn’t tell you about how memory-mapped files could enable new I/O models. They wouldn’t tell you about how IOMMUs could enable kernel-bypass storage and networking. They wouldn’t tell you about how MMUs can introduce lightweight GC barriers. They wouldn’t tell you about how MMUs enable lightweight CoW snapshots for time-trace debugging. Because, although a lot of the hardware existed for these things (and the rest was a fairly small incremental tweak on existing ideas), most of these software uses hadn’t been invented.
CHERI is exactly the same. We have barely scratched the surface of what CHERI can let you build. The BLACKOUT work (presented at CCS and again at CHERITech) is another great example of this. I had never thought of using CHERI as a building block for providing a clean programmer model for avoiding side channels, but some other smart people did and proposed a really interesting model for doing so. I hope future CHERI systems will incorporate something based on this work.
As with MMUs in the early ‘80s, we have no idea what people will be building on top of CHERI in ten or twenty years. Many of these things will be possible on existing implementations, some will require hardware changes. This is why it’s very important for the RISC-V CHERI standard to be designed with agility in mind, so that future hardware can continue to add new and exciting features without breaking backwards compatibility for software. I think we’re on a good path to that.
