Merge branch 'riscv:main' into faf28_spelling_fixes

.github/dependabot.yml

@@ -0,0 +1,8 @@
+---
+# https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#package-ecosystem
+version: 2
+updates:
+  - package-ecosystem: gitsubmodule
+    directory: /
+    schedule:
+      interval: daily

src/attributes.adoc

@@ -65,7 +65,7 @@ endif::[]
 :non-csrrw-and:  <<CSRRWI>>, <<CSRRS>>, <<CSRRSI>>, <<CSRRC>> and <<CSRRCI>>
 
 :TAG_RESET_CSR: The tag of the CSR must be reset to zero. The reset values of the metadata and address fields are UNSPECIFIED.
-:REQUIRE_CRE_CSR: Access to this CSR is illegal if <<section_cheri_disable,CHERI register access is disabled>> for the current privilege.
+:REQUIRE_CRE_CSR: Access to this CSR is illegal if <<section_cheri_disable,CHERI register and instruction access is disabled>> for the current privilege.
 
 :CAP_MODE_VALUE: 0
 :INT_MODE_VALUE: 1

src/insns/load_tag_perms.adoc

@@ -4,8 +4,6 @@ The tag value written to `cd` is 0 if the tag of the memory location loaded is
 +
 If the authorizing capability does not grant <<lm_perm>>, and the tag of `cd` is 1 and `cd` is not sealed, then an implicit <<ACPERM>> clearing <<w_perm>> and <<lm_perm>> is performed to obtain the intermediate permissions on `cd`.
 +
-If the authorizing capability does not grant <<el_perm>>, and the tag of `cd` is 1, then an implicit <<ACPERM>> clearing <<el_perm>> and restricting the <<section_cap_level>> to the level of the authorizing capability is performed to obtain the final permissions on `cd`.
-+
 If the authorizing capability does not grant <<el_perm>>, and the tag of `cd` is 1, then an implicit <<ACPERM>> restricting the <<section_cap_level>> to the level of the authorizing capability is performed.
 If `cd` is not sealed, this implicit <<ACPERM>> also clears <<el_perm>> to obtain the final permissions on `cd` (see <<cap_level_load_summary>>).
 
@@ -15,4 +13,6 @@ Similarly, sealed capabilities are not modified as they are not directly derefer
 NOTE: Missing <<el_perm>> also affects the level of sealed capabilities since notionally the <<section_cap_level>> of a capability is not a permission but rather a data flow label attached to the loaded value.
 However, untagged values are not affected by <<el_perm>>.
 
-NOTE: While the implicit <<ACPERM>> introduces a dependency on the loaded data, microarchitectures can avoid this by deferring the actual masking of permissions until the loaded capability is dereferenced or the metadata bits are inspected using <<GCPERM>> or <<GCHI>>.
+NOTE: While the implicit <<ACPERM>> introduces a dependency on the loaded data, implementations can avoid this by deferring the actual masking of permissions until the loaded capability is dereferenced or the metadata bits are inspected using <<GCPERM>> or <<GCHI>>.
+
+NOTE: When sending load data to a trace interface implementations can choose whether to trace the value before or after <<ACPERM>> has modified the data. The recommendation is to trace the value after <<ACPERM>>.

src/insns/require_cre.adoc

@@ -1 +1 @@
-This instruction is illegal if the <<section_cheri_disable,CHERI register access is disabled>> for the current privilege.
+This instruction is illegal if the <<section_cheri_disable,CHERI register and instruction access is disabled>> for the current privilege.

src/introduction.adoc

@@ -107,8 +107,8 @@ CAUTION: The extension names are provisional and subject to change.
 |<<cheri_default_ext,{cheri_default_ext_name}>> | Stable    | This extension is a candidate for freezing
 |<<sh4add_ext,       {sh4add_ext_name}>>        | Stable    | This extension is a candidate for freezing
 |<<lr_sc_bh_ext,     {lr_sc_bh_ext_name}>>      | Stable    | This extension is a candidate for freezing
-|<<cheri_pte_ext,    {cheri_pte_ext_name}>>     | Prototype | This extension is a prototype, software is being developed to use it to increase the maturity level
-|<<tid_ext,          {tid_ext_name}>>           | Prototype | This extension is a prototype, software is being developed to use it to increase the maturity level
+|<<cheri_pte_ext,    {cheri_pte_ext_name}>>     | Stabilizing | This extension is a candidate for freeze, software evaluation currently ongoing
+|<<tid_ext,          {tid_ext_name}>>           | Stabilizing | This extension is a candidate for freeze, software evaluation currently ongoing
 |<<cheri_levels_ext, {cheri_levels_ext_name}>> with `LVLBITS=1` | Prototype | This extension is a prototype, software is being developed to use it to increase the maturity level.
 |==============================================================================
 

src/level-ext.adoc

@@ -48,7 +48,8 @@ With `LVLBITS=1` there is a single bit comparison, so it behaves as follows:
 NOTE: For `LVLBITS=1` this permission is equivalent to _StoreLocal_ in CHERI v9, Morello and CHERIoT.
 
 [#el_perm,reftext="EL-permission"]
-Elevate Level Permission (EL):: Any capability with its tag set to 1 that is loaded from memory has its <<el_perm>> cleared and its <<section_cap_level>> restricted to the authorizing capability's <<section_cap_level>> if the authorizing capability does not grant <<el_perm>>.
+Elevate Level Permission (EL):: Any unsealed capability with its tag set to 1 that is loaded from memory has its <<el_perm>> cleared and its <<section_cap_level>> restricted to the authorizing capability's <<section_cap_level>> if the authorizing capability does not grant <<el_perm>>.
+If sealed, then only <<section_cap_level,CL>> is modified, <<el_perm>> is unchanged.
 This permission is similar to the existing <<lm_perm>>, but instead of applying to the <<w_perm>> on the loaded capability it restricts the <<section_cap_level,CL>> field.
 
 

src/riscv-hybrid-integration.adoc

@@ -79,9 +79,9 @@ In both encodings:
 * Mode (M)={CAP_MODE_VALUE} indicates {cheri_cap_mode_name}.
 * Mode (M)={INT_MODE_VALUE} indicates {cheri_int_mode_name}.
 
-The current CHERI execution mode is given by the <<m_bit>> of the <<pcc>> and the <<section_cheri_disable,CHERI register access settings>> as follows:
+The current CHERI execution mode is given by the <<m_bit>> of the <<pcc>> and the <<section_cheri_disable,CHERI register and instruction access settings>> as follows:
 
-* The Mode is {cheri_cap_mode_name} when the <<m_bit>> of the <<pcc>> is {CAP_MODE_VALUE}, *and* <<section_cheri_disable,CHERI register access is enabled>> for the current privilege.
+* The Mode is {cheri_cap_mode_name} when the <<m_bit>> of the <<pcc>> is {CAP_MODE_VALUE}, *and* <<section_cheri_disable,CHERI register and instruction access is enabled>> for the current privilege.
 * Otherwise the Mode is {cheri_int_mode_name}.
 
 When the <<m_bit>> can be set, the rules defined by <<ACPERM>> must be followed.
@@ -313,7 +313,7 @@ As shown in xref:CSR_exevectors[xrefstyle=short], <<dddc>> is a data pointer,
 so it does not need to be able to hold all possible invalid addresses.
 
 [#section_cheri_disable]
-=== Disabling CHERI Registers
+=== Disabling CHERI Registers and Instructions
 
 ifdef::cheri_v9_annotations[]
 NOTE: *CHERI v9 Note:* This feature is new and different from CHERI v9's
@@ -324,7 +324,7 @@ it is not possible to disable CHERI checks completely.
 endif::[]
 
 {cheri_default_ext_name} includes functions to disable explicit access to CHERI
-registers.  The following occurs when executing code in a privilege mode that
+registers and instructions.  The following occurs when executing code in a privilege mode that
 has CHERI register access disabled:
 
 * The CHERI instructions in xref:section_cap_instructions[xrefstyle=short] and
@@ -462,8 +462,9 @@ xref:menvcfgmodereg[xrefstyle=short].
 include::img/menvcfgmodereg.edn[]
 
 The CHERI Register Enable (CRE) bit controls whether less privileged levels can
-perform explicit accesses to CHERI registers. When <<menvcfg>>.CRE=1 and <<mseccfg>>.CRE=1,
-CHERI registers can be read and written by less privileged levels. When <<menvcfg>>.CRE=0,
+perform explicit accesses to CHERI registers and execute CHERI instructions.
+When <<menvcfg>>.CRE=1 and <<mseccfg>>.CRE=1, CHERI registers can be read and
+written by less privileged levels. When <<menvcfg>>.CRE=0,
 CHERI registers are disabled in less privileged levels as described in
 xref:section_cheri_disable[xrefstyle=short].
 
@@ -495,8 +496,9 @@ xref:senvcfgreg[xrefstyle=short].
 include::img/senvcfgreg.edn[]
 
 The CHERI Register Enable (CRE) bit controls whether U-mode can perform
-explicit accesses to CHERI registers. When <<senvcfg>>.CRE=1 and <<menvcfg>>.CRE=1 and
-<<mseccfg>>.CRE=1 CHERI registers can be read and written by U-mode. When <<senvcfg>>.CRE=0,
+explicit accesses to CHERI registers and execute CHERI instructions. When
+<<senvcfg>>.CRE=1 and <<menvcfg>>.CRE=1 and <<mseccfg>>.CRE=1 CHERI registers
+can be read and written by U-mode. When <<senvcfg>>.CRE=0,
 CHERI registers are disabled in U-mode as described in
 xref:section_cheri_disable[xrefstyle=short].
 

src/riscv-integration.adoc

@@ -425,8 +425,7 @@ include::generated/csr_renamed_purecap_mode_u_table_body.adoc[]
 === Machine-Level CSRs
 
 {cheri_base_ext_name} extends some M-mode CSRs to hold capabilities or
-otherwise add new functions. <<pcc>> must grant <<asr_perm>> to access M-mode
-CSRs regardless of the RISC-V privilege mode.
+otherwise add new functions. <<asr-perm>> in the <<pcc>> is typically required for access.
 
 [#mstatus,reftext="mstatus"]
 ==== Machine Status Registers (mstatus and mstatush)
@@ -758,7 +757,7 @@ a CHERI fault taken into M-mode, <<mtval>> is written with the
 MXLEN-bit effective address which caused the fault according to the existing
 rules for reporting load/store addresses from cite:[riscv-priv-spec]. In this case
 the TYPE field of <<mtval2>> shown in xref:mtval2-cheri-type[xrefstyle=short] is
-set to {cheri_excep_type_data}. For all other CHERI faults it is set to zero.
+set to {cheri_excep_type_data}. For all other CHERI faults <<mtval>> is set to zero.
 
 The behavior of <<mtval>> is otherwise as described in cite:[riscv-priv-spec].
 
@@ -832,8 +831,7 @@ CHERI violations have the following order in priority:
 === Supervisor-Level CSRs
 
 {cheri_base_ext_name} extends some of the existing RISC-V CSRs to be able to
-hold capabilities or with other new functions. <<pcc>> must grant <<asr_perm>>
-to access S-mode CSRs regardless of the RISC-V privilege mode.
+hold capabilities or with other new functions. <<asr-perm>> in the <<pcc>> is typically required for access.
 
 [#stvec,reftext="stvec"]
 ==== Supervisor Trap Vector Base Address Register (stvec)
@@ -1050,7 +1048,8 @@ include::img/stval2reg.edn[]
 
 === Unprivileged CSRs
 
-Unlike machine and supervisor level CSRs, {cheri_base_ext_name} does not require
+In {cheri_base_ext_name}, the only register that requires <<asr_perm>> is <<utidc>>
+(for updates but not for reads), and all other unprivileged CSRs do not require
 <<pcc>> to grant <<asr_perm>> to access unprivileged CSRs.
 
 === CHERI Exception handling
@@ -1187,17 +1186,28 @@ this section describes how invalid address handling must be supported in
 {cheri_base_ext_name} when accessing CSRs, branching and jumping, and
 accessing memory.
 
-===== Accessing CSRs
+===== Updating CSRs
 
-The following procedure must be used when executing instructions, such
-as <<CSRRW>>, that write a capability A to a CSR that cannot hold all invalid
-addresses:
+Some capability-holding CSRs need not be able to hold all invalid virtual addresses.
+Prior to writing to those CSRs, implementations may convert an invalid address into some other invalid address that the CSR is capable of holding.
+This is problematic for CHERI as updating the address may invalidate the bounds as a result, if the bounds are not those of the <<infinite-cap>> capability.
+
+Some situations may require that a CSR may be updated to hold a capability with an invalid address:
+
+* executing instructions, such as <<CSRRW>>
+* hardware updates to CSRs such as storing the <<pcc>> (which becomes capability A) into
+ <<mepcc>>/<<sepcc>> etc. when taking an exception.
+
+In order to satisfy the definitions of such CSRs and preserve capability system invariants, the following procedure must be used as part of write-back to the CSR:
 
 . If A's address is invalid and A does not have infinite bounds (see
 xref:section_cap_encoding[xrefstyle=short]), then A's tag is set to 0.
 . Write the final (potentially modified) version of capability A to the CSR e.g.
 <<mtvecc>>, <<mepcc>>, etc.
 
+NOTE: When A's address is invalid and happens to match an invalid address which the CSR
+can hold, then it is implementation defined whether to clear A's tag.
+
 ===== Branches and Jumps
 
 Control transfer instructions jump or branch to a capability A which can be: