About

• Specification Name: CHERI

• Task Group: RVG-148 - Getting issue details... STATUS

• Task Group Charter: https://github.com/riscv-admin/cheri-tg/blob/main/charter.adoc Charter

• Spec Jira: RVS-2141 - Getting issue details... STATUS

Background

The goal of the CHERI TG is to define a capability-based security extension.

CHERI provides deterministic spatial and temporal memory safety, and low-cost scalable compartmentalization features and is a fundamental step forward in terms of security for the RISC-V ecosystem.

Building on over a decade of pioneering research by the University of Cambridge and SRI International, the CHERI technology has been implemented by Arm on the Morello 7nm SoC evaluation platform, and many processors have been developed by academia and the industry (Microsoft, Google, Codasip, lowRISC, …)

Overview

The CHERI extension adds a new data type to RISC-V: the CHERI capability. This can be thought of as a (2*XLEN)-bit pointer with bounds information, permissions (e.g. read/write), type information and an out-of-band hardware-tracked validity tag. In combination with new instructions, this allows for fine-grained compartmentalization and deterministic memory safety. Importantly, any instruction operating on capabilities can only reduce the access rights granted and any attempt to amplify (e.g. by growing the bounds) will clear the validity tag.

When a core implements CHERI, the general purpose registers and CSRs that hold pointers (e.g. xtvec) are widened to capability size and the memory subsystem propagates the validity tags to memory. New instructions operating on the extended GPRs perform bounds and permission checks when loading/storing to enforce memory safety and new jump instructions allow for efficient compartment switching.

For a more detailed description, please see the introduction of the specification document: https://riscv.github.io/riscv-cheri/#_introduction

Stakeholders Identification

References: Active Groups and Specifications Under Development

We will work closely with the following groups to ensure the extension meets all requirements:

• Security HC as well as Priv+Unpriv IC

• CHERI SIG

• psABI (to define the new pure-capability ABI)

• Architectural Testing (to define a testsuite for CHERI-RISC-V)

• Formal modelling (to upstream a CHERI-RISC-V Sail model)

• Apps and Tools Software HC

• SBI Specification

Design Considerations

The CHERI extension has been designed to be fully binary compatible with existing RISC-V code. When the extension is enabled, it is also possible to recompile code in a mode that uses capability registers (instead of integer GPRs) for all accesses, the so-called pure-capability programming environment.

Because of limited opcode space, it is not feasible to add new variations of every (vector) load/store instruction using a capability base register, so CHERI adds a decoding mode bit to the program counter that allows changing the interpretation of the base operand between integer and capability.

Proof-of-Concept and Tests

The CHERI specification has been validated in multiple operating systems:

• CheriBSD (an adaptation of FreeBSD) is the most mature CHERI software ecosystem with a full graphical desktop stack and over 10,000 packages making full use of CHERI.

• Linux support is also available, but currently only runs a smaller set of userspace applications compared to CheriBSD.

• OpenSBI and U-Boot have also been adapted to make use of CHERI.

• Many embedded operating systems have been adapted: FreeRTOS, sel4, RTEMS, etc.

In addition to these operating systems, many thousands of open-source projects have been compiled for purecap CHERI and hundreds of patches have been upstreamed.

In terms of simulators and formal models, a CHERI extended versions of QEMU and Sail are openly available.

In terms of ISA tests, Codasip has an extensive test suite and Cambridge has created a differential testing framework that works with CHERI.

Software Ecosystem Impacts

While CHERI is a larger extension, in most cases there is no need to explicitly use compiler intrinsics - instead enabling the extension and the appropriate ABI flag will transparently make use of new all instructions and result in a memory-safe application.

However, there are cases where explicit changes are required:

• Operating system context switching logic will need updating for the new registers (as seen in the PoCs).

• Low-level libraries and language runtimes may require explicit usage of intrinsics (e.g. setting bounds on resulting pointers for memory allocators).

• Applications that hardcode assumptions about pointer sizes may require minor changes to source code.

Importantly, the CHERI extension is fully binary compatible with existing RISC-V binaries, so there is no requirement to use this new ABI. Applications function as before, while parts of the software stack that opt-in to the new extension (e.g. the firmware, hypervisor, kernel, other programs) can run in a memory safe and compartmentalized environment,

Freeze Checklists

Key Milestones

Additional Notes