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
47 stars 26 forks source link

Allowing using alternative capability encodings #324

Closed andresag01 closed 2 days ago

andresag01 commented 2 months ago

As discussed in this week's CHERI TG meeting, it is sometimes desirable to use alternative capability encodings, particularly in RV32. However, the CHERI RISC-V specification currently mandates capability encodings for RV32 and RV64 in the base extension Zcheripurecap. A proposal to get around this restriction is to split out the capability encoding (i.e. most of Chapter 2) into a separate CHERI RISC-V extension and include a paragraph indicating that the encoding described in this specification could be replaced with an alternative encoding.

There is precedent for a similar arrangement in the ratified RISC-V privileged specification which has the following text as a note in the introduction:

We briefly note that the entire privileged-level design described in this document could be replaced with an entirely different privileged-level design without changing the unprivileged ISA, and possibly without even changing the ABI...... For simplicity of expression, the text is written as if this was the only possible privileged architecture.

The CHERI RISC-V spec would require that alternative encodings at the very least support the minimal set of features that underpin the base CHERI instructions. For example, the alternative encoding would need to support all the base architectural permissions and sentries, and could add new permissions.

To enable this flexible arrangement, we would need to review the existing CHERI RISC-V instructions and features to ensure that nothing is defined in such a way that it is directly dependent on the capability encoding. For example, the current description of ACPERM springs to mind because it restricts the allowed combinations of set permissions depending on what can be encoded in the AP field. We probably need to move these restrictions into the new capability encoding extension. Another example is probably the CHERI execution mode which is alluded to in Chapter 2 although this is not part of Zcheripurecap.

andresag01 commented 2 months ago

@davidchisnall, @tariqkurd-repo: What's your view on this?

davidchisnall commented 2 months ago

I think it is the right approach. I believe @nwf-msr has a concrete proposal along these lines underway.

andresag01 commented 2 months ago

Thanks! @nwf-msr could you share the details of your proposal?

nwf-msr commented 2 months ago

Absolutely. I have just posted it to the list: https://lists.riscv.org/g/tech-tg-cheri/message/6 .