Ensure GCPERM result is forwards-compatible with software #501
Conversation
|
We could also report a hardcoded 1 here since not implementing the levels extension ensures that all loads/stores behave as if the permissions were always granted. But I think being able to easily detect whether the levels ext is implemented probably makes more sense? |
arichardson
force-pushed
the
levels-clarification
branch
2 times, most recently
from
2b4bbb4 to
4d8e589
Compare
arichardson
changed the title
|
If we go for RES1 on GCPERM/ACPERM, does that mean we need to have all unused bits hardwired to one? That would break patterns like |
|
These are all good questions that need to be thought through carefully, hence my repeated invitations to think about the problem (e.g. I mentioned this back in October 2023 on our internal Slack)... |
arichardson
force-pushed
the
levels-clarification
branch
from
4d8e589 to
13125db
Compare
|
Updated to reserve bits 0-23 as 1 and 24-xlen-1 as zero in the GCPERM mask. Also added a note on how new permissions need to be allocated. |
arichardson
changed the title
When new extensions add permissions that are subsets of current permissions (e.g. Zcherilevels refines loads/stores), then a system that does not support these permissions should still report ones in GCPERM to ensure that code that inspects permissions knows that the load/store behaves as if all of these permission bits were set. We reserve the low 24 bits as ones (to be used as refinements of the current permissions) and the upper 8 (40 for RV64) bits as zeros (to be used for new permissions that aren't subsets (e.g. seal/unseal/compartment ID). Partially addresses riscv#502
arichardson
force-pushed
the
levels-clarification
branch
from
13125db to
dc89511
Compare
|
Added note on ACPERM behaviour based on offline feedback from @LawrenceEsswood. This matches what was previously discussed in the CHERI meetings, so will merge this now. We can always adjust the number of reserved one bits during review. |
When new extensions add permissions that are subsets of current permissions
(e.g. Zcherilevels refines loads/stores), then a system that does not
support these permissions should still report ones in GCPERM to ensure that
code that inspects permissions knows that the load/store behaves as if all
of these permission bits were set.
We reserve the low 24 bits as ones (to be used as refinements of the current
permissions) and the upper 8 (40 for RV64) bits as zeros (to be used for
new permissions that aren't subsets (e.g. seal/unseal/compartment ID).
Partially addresses #502