Closed andresag01 closed 2 days ago
@davidchisnall, @tariqkurd-repo: What's your view on this?
I think it is the right approach. I believe @nwf-msr has a concrete proposal along these lines underway.
Thanks! @nwf-msr could you share the details of your proposal?
Absolutely. I have just posted it to the list: https://lists.riscv.org/g/tech-tg-cheri/message/6 .
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:
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.