How CHERIoT Provides Strong and Usable Isolation Without an MMU

16 points by rrampage

david_chisnall

I've been writing about CHERIoT again (still?). This one is trying to cover a bit the split between:

Stuff we did in CHERIoT RTOS that we think is a good idea and everyone should do on all CHERI systems.
Stuff we did in CHERIoT RTOS that we think is a good idea for very resource-constrained systems and no one should do if they have more than a few MiBs of RAM.

Happy to answer questions here!

manfred

Would it make sense to build an OS that uses these abstractions when you don't have hardware support for capabilities? For example, to provide a platform for application developers to get more comfortable with them?
- david_chisnall
  
  I don't think it would be feasible, unless you're thinking of something like Singularity / Midori where you run all user software in some managed language.
  
  The key thing that CHERI gives you is safe fine-grained sharing. The ability to share at the granularity of an object, or more importantly, an object graph enables a whole load of completely different designs to traditional systems where sharing is at the granularity of pages.
  
  You can't really build the same abstractions without either CHERI or some kind of soft CHERI. It's a huge shame that WebAssembly decided to be a virtual PDP-11 instead of a virtual CHERI, because something like that might be interesting as a base for a 'look, CHERI gives you the same thing as this but faster' platform.
  - spc476
    
    Did anyone working on CHERI offer to work with or help the WebAssembly folk?
  - junon
    
    Build a VM, get the DX right, and it'll be used. Not a single wasm runtime out there is fun to integrate. I'm currently integrating WASM into a project at work and it's dreadful.
    
    And don't put "web" in the name!
- aka_dude
  
  Are there any plans on building a general-purpose OS for CHERI?
  - fanf
    
    https://www.cheribsd.org/ has been around for over 10 years
- hjvt
  
  In CHERIoT, these things are simply exposed as sealed capabilities (opaque pointers). A compartment can hand out tamper-proof type-safe pointers to API consumers. For example, the TCP/IP compartment exposes a socket by returning a sealed capability that points to the socket state. The caller can hand this to other compartments, embed it in other data structures, and so on. The Transport Layer Security (TLS) layer stores this pointer in a structure that includes TLS session state and then returns a sealed capability to that structure to callers.
  
  I don't entirely understand why that's useful.
  Is the idea that you basically can handle a kernel space pointer to user-space, and then have user-space call you with that pointer, and have trust that it is a priori valid?
  That is the implementation for, ie, the write sys all can be simplified to essentially just *io_sealed_ptr = *user_data;, a straightforward copy?