> 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  for a general overview.
Interestingly, there is a section in their specification describing a short overview of how it could be applied to RISC-V.
Its main competition was SAFE architecture that used tags. It has been commercialized as 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.
Unix Hater's Handbook https://web.mit.edu/%7Esimsong/www/ugh.pdf
it is important to always keep a critical view, most of the time we are on a false summit.
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.