Computer Laboratory


CHERI frequently asked questions (FAQ)

Here are answers to some of the common questions we've received (or in some cases, anticipate) about CHERI. See the BERI FAQ for questions about the BERI platform.

CHERI: Capability Hardware Enhanced RISC Instructions

What is CHERI?

CHERI refers to Capability 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. Memory capabilities describe bounded regions of virtual-address space, which may be sealed and combined with protection-domain crossing to implement software compartmentalisation. CHERI is targeted by the compiler and used to represent programming-language level protection properties, in contrast to conventional memory management units (MMUs) that are used to construct page-based virtual memory by operating systems. In CHERI, the capability coprocessor and MMU live side by side, hence being a hybrid model, providing strong protection guarantees while allowing significant compatibility with current software at both binary and source-code levels -- a technique inspired by our earlier work on Capsicum, a hybrid capability-system model for UNIX.

CHERI also refers to our prototype implementation of the ISA, embodied in a capability coprocessor in the BERI implementation. We have released the BERI source code, along with adaptations of the FreeBSD operating system and LLVM compiler suite supporting CHERI. Please see our hardware downloads and software downloads pages for more information. Development of BERI and CHERI was supported by grants from DARPA and Google.

What is a hybrid capability system?

Capabilities are unforgeable tokens of authority that may be passed from subject to subject (delegated) granting rights to objects; typically, capabilites incorporate both a reference to an object and a mask of permissions reflecting possible operations or methods on the object. Conventional capability systems constrain executing code such that executing code can access only objects as permitted via capabilities; this limitation might be enforced by constraints imposed by an ISA, operating-system API, programming language, network protocol, or even by static or dynamic limits imposed on a program using code analysis or transformation. Microkernels (such as seL4) often implement capability systems as their fundamental security model as the model provides a strong mechanism on which many different policies can be implemented.

A hybrid capability system is one in which more conventional systems designs (such as a UNIX kernel or RISC processor) are adapted to support a capability model such that some, but not all, code is limited by capability-system constraints, and a set of pragmatic tradeoffs are adopted to allow conventional system objects to be exposed via more capability-esque models. For example, Capsicum composes a capability-system model with the UNIX API, treating file descriptors as capabilities, and allowing selected processes to be marked as losing access to global system namespaces, in effect, imposing a capability system. Hybrid capability systems offer improved adoptability by allowing components of existing applications to be selectively migrated to a least-privilege programming model, although at the cost of reduced robustness and security as compared to a pure capability system and application suite written entirely with those goals in mind.

What is the difference between BERI and CHERI?

BERI is the Bluespec Extensible RISC Implementation, a hardware description of a 64-bit pipelined RISC processor, as well as debugging tools and C-language simulated buses and devices. CHERI is a set of ISA and implementation extensions providing fine-grained memory protection and support for scalable software compartmentalisation developed as part of the CTSRD Project joint between SRI International and the Universit of Cambridge Computer Laboratory. The BERI implementation includes optionally compiled support for CHERI, enabled via the CP2 flag at compile-time. CHERI occupies the coprocessor-2 instruction encoding space, and must be explicitly enabled. You may find Capability Hardware Enhanced RISC Instructions: CHERI Instruction-set architecture (UCAM-TR-850) and our ISCA 2014 paper The CHERI capability model: Revisiting RISC in an age of risk useful reading if this is of interest to you.

Why 32 capability registers?

As our starting point was the 64-bit MIPS ISA, we made a number of design choices to maximise congruence in the CHERI ISA, including selecting 32 capability registers to correspond to the 32 general-purpose registers in the MIPS ISA. This is an arbitrary choice, and one we may revisit due to its size: we believe that a 16-entry capability register file would be entirely adequate. We could also imagine splitting a 16-entry file into two parts, one intended for userspace, and the other for privileged use, to reduce system-call overhead.

Could you do it with fewer than 256 bits?

256 bits arises out of the desire to support three full 64-bit values (base, length, and type/cursor). A number of proposals have been made for how pointers can be compressed when used in fat-pointer contexts, such as the Low-Fat Pointer scheme proposed by Kwon, et al., which could help reduce this size. In our 2014 ISCA paper, we performed simulations that demonstrated that capability size does play a signficant role in performance, and believe that there are plausible 128-bit layouts that retain most of the functionality we desire using a somewhat reduced available address space combined with modest compression schemes. However, based on our goals to support many current software designs via source-level compatibility, we believe that it is important to retain byte-level granularity and so would avoid trying to reduce bit footprint by, for example, reducing this to 32-bit or 64-bit granularity. This is particularly important to handle packet and string parsing.

Why tagged memory?

Many memory-based attacks on contemporary hardware-software designs rely on corrupting pointers or lengths. Tags provide strong pointer-integrity guarantees that are difficult to implement efficiently without hardware support. Tags add one bit of memory for every 256 bits of data, leading to negligible memory overhead; they are maintained with cache lines and so obey normal cache-coherency rules. In CHERI, we partition physical memory, setting aside a portion to hold tags, rather than requiring a change in DIMM interface. Currently, that partition is hard-coded, but it would ideally be managed by the firmware or software supervisor.

How specific is CHERI to the MIPS ISA?

In short, not very: we used the 64-bit MIPS ISA as a starting point as we required large address spaces and access to a conventional software stack, but CHERI is at heart a RISC rather than MIPS-ISA approach. CHERI is "localised" to MIPS in the sense that it occupies a MIPS-ISA coprocessor encoding, and we adopt a number of design conventions congruent to the MIPS ISA to ease compiler support, but it is easy to imagine applying these ideas to other 64-bit RISC ISAs such as ARMv8 and RISC-V. The current CHERI ISA, as well as information on our design choices and potential applicability to other RISC ISAs, is described in our Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture technical report.

How does CHERI compare with other memory-protection schemes?

Our 2014 ISCA paper includes a detailed comparison of the protection semantics and performance of CHERI as compared to other schemes, including software bounds checking, Intel MPX, HardBound, Mondriaan, and M-Machine. Each selects a different point in a larger tradeoff space. Key design choices that have motivated CHERI include a focus on providing strong protection for C-language pointers, hybridization with MMU-based virtualization, avoidance of hardware lookup tables and associative structures in the microarchitecture, and strong support for existing software stacks.