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 28 forks source link

M bit should be inverted #303

Closed jrtc27 closed 3 months ago

jrtc27 commented 3 months ago

Currently, we have M=1 for capability mode, but M=0 either means integer mode, if supported, or capability mode, if integer mode is not. Moreover, the infinite capability is defined to have M=0, so you have to SCMODE it if you want to derive things from it that should remain in capability mode. It would be much more natural to have M=0 mean capability mode, as the thing that you are likely using if interacting with capabilities, and then the bit only needs to be encoded to represent a non-zero state when you want to use legacy mode, making things unambiguous. This also means the infinite capability would be capability mode. Note that null is unaffected since it is non-X and thus M does not exist there.

tariqkurd-repo commented 3 months ago

why is the infinite-cap in integer mode?

I support this change - I think it makes the definition clearer if it doesn't cause problems.

arichardson commented 3 months ago

I guess this means we have to define the PCC reset capability to be != infinite-cap since it has to be integer mode if the core supports hybrid? That's fine by me but probably needs calling out explicitly?

tariqkurd-repo commented 3 months ago

For 100% compatibility then it must boot into integer mode, yes. The mode is orthogonal to the other features of the infinite-cap so I think we can make it work..... I'll give it a go