search

riscv / riscv-cheri

This repository contains the CHERI extension specification, adding hardware capabilities to RISC-V ISA to enable fine-grained memory protection and scalable compartmentalization.
https://jira.riscv.org/browse/RVG-148
Creative Commons Attribution 4.0 International
37 stars 24 forks source link

Generic hardware revocation support? #254

Open jonwoodruff opened 1 month ago

jonwoodruff commented 1 month ago

It is possible that CHERI-RISC-V implementations may have hardware acceleration for revocation, and it would be nice to have a generic extension that supports several strategies of hardware temporal safety/revocation acceleration.

For example, CHERIoT supports a hardware revocation bitmap such that, when memory is marked in the bitmap as "revoked", all capabilities that are loaded henceforth whose base points into the revoked range will have their tags cleared. This has the property that the revoked memory becomes instantly impossible to reference.

In addition, one could imagine a DMA engine that sweeps memory, performing "capability revoked" checks concurrent to the main CPU.

In the way of an example, potentially, such an extension might allow incrementing the generation in a CSR, and indicating areas of revoked memory using an instruction with a capability operand that points to the range of addresses to be freed/revoked. The architecture might guarantee (either by hardware or m-mode software) that objects marked as revoked in generation - 2 is available to reuse. (Generation-1 would be "being swept/revoked now", and current generation is still being marked.) An architecture similar to CHERIoT would need hardware support for painting the shadow map corresponding to the addresses in the capability presented in the new instruction.

Care might be taken to ensure that memory can be considered free to reuse without having to start another sweep, as the above design indicates. Maybe a "all revocations done" CSR flag would do the trick, letting you know that Generation-1 is free to reuse.

davidchisnall commented 1 week ago

For big cores, this absolutely does not want to be part of the core ISA. It is most likely to be implemented in the hardware data mover and so should not be specified until that has been specified architecturally (e.g. Intel QAT).

The CHERIoT design originated from scaling down a design for a 128-core system with CHERI, MTE, and a hardware data mover. The composition with MTE-like tagging is an important step because it means that all revocation state is architectural (expressed in the capability, memory colouring, or page-table state). Even then, there are a lot of subtle corner cases and there are some interesting implications on the memory model.

If you want to get to hardware revocation for MMU systems, start with memory colouring. Make sure you add the atomic decrement colour and check if zero instruction.