From dc89511cddd36d741397e8b13dd4a8820efb8d8c Mon Sep 17 00:00:00 2001 From: Alex Richardson Date: Tue, 7 Jan 2025 11:50:27 -0800 Subject: [PATCH] Ensure GCPERM/ACPERM is forwards-compatible with software 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 https://github.com/riscv/riscv-cheri/issues/502 --- src/img/acperm_bit_field.edn | 10 ++++++---- src/insns/acperm_32bit.adoc | 9 +++++++-- src/insns/gcperm_32bit.adoc | 7 +++++++ 3 files changed, 20 insertions(+), 6 deletions(-) diff --git a/src/img/acperm_bit_field.edn b/src/img/acperm_bit_field.edn index 1412c887..e1442912 100644 --- a/src/img/acperm_bit_field.edn +++ b/src/img/acperm_bit_field.edn @@ -6,13 +6,14 @@ (def left-margin 100) (def right-margin 100) (def boxes-per-row 32) -(draw-column-headers {:height 20 :font-size 18 :labels (reverse ["0" "1" "2" "3" "4" "5" "6" "" "" "SDPLEN+5" "" "" "" "" "" "15" "16" "17" "18" "19" "" "" "" "" "" "" "" "" "" "" "" "XLEN-1"])}) +(draw-column-headers {:height 20 :font-size 18 :labels (reverse ["0" "1" "2" "3" "4" "5" "6" "" "" "SDPLEN+5" "" "" "" "" "" "15" "16" "17" "18" "19" "" "23" "" "" "" "" "" "" "" "" "" "XLEN-1"])}) -(draw-box "Reserved" {:span 13}) +(draw-box "Reserved 0" {:span 10}) +(draw-box "Reserved 1" {:span 3}) (draw-box "R" {:span 1}) (draw-box "X" {:span 1}) (draw-box "ASR" {:span 1}) -(draw-box "Reserved" {:span 6}) +(draw-box "Reserved 1" {:span 6}) (draw-box "SDP" {:span 4}) (draw-box "C" {:span 1}) (draw-box "CL" {:span 1}) @@ -21,7 +22,8 @@ (draw-box "LM" {:span 1}) (draw-box "W" {:span 1}) -(draw-box "XLEN-19" {:span 13 :borders {}}) +(draw-box "XLEN-23" {:span 10 :borders {}}) +(draw-box "5" {:span 3 :borders {}}) (draw-box "1" {:span 1 :borders {}}) (draw-box "1" {:span 1 :borders {}}) (draw-box "1" {:span 1 :borders {}}) diff --git a/src/insns/acperm_32bit.adoc b/src/insns/acperm_32bit.adoc index ffe37729..86cd1236 100644 --- a/src/insns/acperm_32bit.adoc +++ b/src/insns/acperm_32bit.adoc @@ -80,9 +80,14 @@ The behavior of currently illegal combinations from <> is to clear [#acperm_bit_field] include::../img/acperm_bit_field.edn[] -NOTE: The <>, <> and <> fields are only defined if the implementation supports <>. +NOTE: The <>, <> and <> fields are only modifiable if the implementation supports <>. -NOTE: Even though being included here <> is not considered an architectural permission. + +NOTE: Even though included here <> is not considered an architectural permission. + + +NOTE: If a future extension adds a new permission that is a refinement of an existing permission (e.g. finer-grained <>), then clearing the superset must also clear the refined permission. +This ensures software forward-compatibility: for example, a kernel that does not know about finer-grained <> subsets must still be able to prevent all access to privileged instructions and CSRs by clearing <>. Exceptions:: include::require_cre.adoc[] diff --git a/src/insns/gcperm_32bit.adoc b/src/insns/gcperm_32bit.adoc index 36c06a42..68731331 100644 --- a/src/insns/gcperm_32bit.adoc +++ b/src/insns/gcperm_32bit.adoc @@ -25,6 +25,7 @@ Convert the unpacked AP permissions as well as the SDP fields of capability `cs1 into a bit field, with the format shown in xref:gcperm_bit_field[xrefstyle=short], and write the result to `rd`. A bit set to 1 in the bit field indicates that `cs1` grants the corresponding permission. +All bits in the `[0:23]` range that are reserved or assigned to extensions that are not implemented by the current hart always report 1. + If the AP field cannot be produced by <> then all architectural permission bits in `rd` are set to 0. @@ -33,6 +34,12 @@ permission bits in `rd` are set to 0. [#gcperm_bit_field] include::../img/acperm_bit_field.edn[] +NOTE: When {cheri_levels_ext_name} is not implemented, the `CL`, `SL`, and `EL` fields always report 1. +This ensures forwards-compatibility since loads/stores on a core without {cheri_levels_ext_name} behave as if these permissions are always present. + +NOTE: Any future extension that defines new permission that are a refinement of existing permissions (e.g. finer-grained <>) must be allocated to the bits that are currently reported as 1 to ensure forward-compatibility. +Completely new permissions (e.g. sealing) should use the bits that are reported as zero in the current specification. + Exceptions:: include::require_cre.adoc[]