CHERI: Capability Hardware Enhanced RISC Instructions

The FAQ[0] provides a better overview,

> CHERI refers to Capability Hardware Enhanced RISC Instructions, an Instruction-Set Architecture (ISA) extension that implements a hybrid capability-system model providing fine-grained memory protection and scalable software compartmentalisation within processes. CHERI capabilities are a new hardware data type intended to support the robust and secure implementation of pointers. Capabilities hold a virtual address as well as metadata describing the memory resources referenced by the pointer (bounds, permissions, ...) ... The architecture (and hence hardware) protects pointers in registers and memory, controlling their creation and use (e.g., nonforgeability and nonbypassability), manipulation (e.g., enforcing monotonicity on bounds modifications and permissions), ensuring only authorized use (e.g., dereference within bounds), and also their in-memory integrity (e.g., detecting pointer corruption or injection). Policies are expressed by the software (OS, compiler, language runtime, and application) and enforced by the hardware.

See also [1] for a general overview.

[0] https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri...

[1] https://en.wikipedia.org/wiki/Capability-based_addressing

They have ported FreeBSD to CHERI to have a real world system demonstrate all the features. This includes existing applications to show the tradeoffs between hybrid mode and full use of capabilities.

Interestingly, there is a section in their specification describing a short overview of how it could be applied to RISC-V.

Follows a rich tradition described here:

https://homes.cs.washington.edu/~levy/capabook/

Its main competition was SAFE architecture that used tags. It has been commercialized as CoreGuard.

http://www.crash-safe.org/papers.html

https://dovermicrosystems.com/coreguard/

There's lots of them for stuff like memory safety (esp Watchdog Lite or Hardbound) and control-flow integrity. The above were more thorough. One might also build a capability-secure OS or language on CHERI for more consistency and exploitation of its capabilities.

Wasn’t this a key element of the Multics architecture, one the Thompson and Ritchie were explicit about leaving behind?

Hardware capabilities seem like they could be an interesting alternative to traditional separate address space memory management; they could allow you to have fine grained access control to individual objects in memory without having to have separate address spaces via a TLB.

However, they seem to be trying to stuff so much into the capability; there's a base, a length, and offset, permissions, sealing bits, extra bits reserved for user permissions, and so on. They're 256 bytes, 4 times the size of a normal pointer, plus an extra tag bit for validity.

They do have a compressed 128 bit version, with various alignment constraints, but it seems like they are trying to stuff too much functionality into these capabilities.

I feel like it might be more instructive to start from a much simpler capability design, with just simple fat pointers with a few bits used for tagging (due to alignment, or not needing to use the full 64 bit address space), and see how far you can get with that, without adding in all of the extra features and needing huge pointers or funky compression that imposes much stricter alignment constraints.

Does anyone know how this relates to the new ARM pointer validation stuff Apple just shipped on the XS? I haven't seen much press about this except on Risky Biz.

Interesting. But the Altera board it runs on costs $2,995. Out of my league, unfortunately. At least privately. And professionally, I doubt that I can talk my boss into buying one.