CHERIoT Memory Subsystem Technical Specification

RegressionVersionStagesResults
cheriot_mem_sys1.0.0D0, V0

Overview

This document specifies the CHERIoT memory subsystem. The subsystem sits between the CHERIoT-capable Ibex core and the main crossbar and follows the Comportability Specification.

A CHERIoT capability is 65 bits in size: 32 bits pointer, 32 bits of metadata for the pointer, and a single validity tag bit. OpenTitan keeps a 32-bit interconnect, so capabilities are transferred in two consecutive 32-bit accesses, and the tag is carried on a sideband signal, which shares the handshakes, next to the TL-UL structs. The subsystem is responsible for handling and storing the validity tag bit. It splits a data access of Ibex into the data access towards the interconnect and a tag access towards a dedicated and guarded meta SRAM.

The capability validity tags for main SRAM and NVM, and the revocation bitmap for the heap stored in the main SRAM are stored using a sram_ctrl.

Features

  • Splits Ibex data accesses into a data access towards the interconnect and a capability tag access towards the meta SRAM, and joins their responses.
  • Read-modify-write access to implement bit-granular access to capability bits.
  • Clears any capability tag of any location written by a non-capability store.
  • Lets a capability store to the read-only NVM set the capability’s tag when the NVM already holds the stored capability (write-to-read-and-compare, WTRC), and answers any other capability store to the NVM with an error.
  • Exposes the revocation bitmap into the core’s address map and serves the core’s TRVK filter.
  • A background revocation engine that sweeps a range of capabilities within a tagged region and clears the tag of every capability whose base is revoked, leaves capabilities the core writes meanwhile alone, raises an interrupt when a sweep completes, and counts the sweeps that ended without an error in an epoch register of the form the CHERIoT RTOS revoker uses.
  • Per-port access checking: each of the four requesters may only reach the meta SRAM region it owns, with word-granular accesses only.
  • Fatal alert on a CSR bus integrity fault, a meta SRAM response integrity fault, a meta SRAM device error, a fault the revocation engine reports, or what the core cannot produce around a capability store to the NVM (an integrity fault, a partial store, or a request out of sequence).

Description

The CHERIoT HWIP has four requesters towards the meta SRAM and arbitrates between them:

  • The RMW filter, which performs the bit-granular tag update for the core’s tag filter and for the revocation engine’s tag filter.
  • The core’s TRVK filter, which reads the revocation bitmap on every capability load.
  • The revocation engine’s TRVK filter, which reads the revocation bitmap for every capability it sweeps.
  • The system, which reads and writes the revocation bitmap through the revbm memory window.

Each requester passes an access checker module that confirms the address falls in the region that the requester owns and that the operation is a full-word read or write. Invalid accesses receive a TL-UL error response. Because the capability tag regions are not reachable from the revbm window, software can neither read nor write capability tags.

Requests that the subsystem generates or rewrites get command and data integrity, so end-to-end bus integrity is intended to hold from the Ibex lockstep through the CHERIoT HWIP domain to the storage cells; this relies on lockstep operation of the CHERIoT memory subsystem, which is not implemented yet. An integrity fault raises the fatal_fault alert.

See the Theory of Operation for the datapath, the meta SRAM address map, and the access-check rules. See the Programmer’s Guide for driving the background revocation engine.