From 3d4c1e8e46945dd78d24a00bf8b1ab7e1f38e0d6 Mon Sep 17 00:00:00 2001 From: Alexander Richardson Date: Thu, 30 Jan 2025 04:34:20 -0800 Subject: [PATCH] Minor changes from read-through (#511) These fixes are based on discussing the current spec with @LawrenceEsswood. Minor clarifications no real changes. --------- Signed-off-by: Tariq Kurd Co-authored-by: Lawrence Esswood Co-authored-by: Tariq Kurd --- src/debug-integration.adoc | 5 ++--- src/hypervisor-integration.adoc | 2 +- src/riscv-hybrid-integration.adoc | 15 +++++++++------ src/riscv-integration.adoc | 11 ++++++----- 4 files changed, 18 insertions(+), 15 deletions(-) diff --git a/src/debug-integration.adoc b/src/debug-integration.adoc index cabf25b4..fa2b85f7 100644 --- a/src/debug-integration.adoc +++ b/src/debug-integration.adoc @@ -117,10 +117,9 @@ to this specification. The <> metadata has no architectural effect in debug mode. Therefore <> is implicitly granted for access to all CSRs and no CHERI instruction fetch faults are possible. -<> (and consequently <>) are updated with the +On debug mode entry <> (and consequently <>) are updated with the capability in <> whose address field is set to the address of the next -instruction to be executed as described in cite:[riscv-debug-spec] upon -debug mode entry. +instruction to be executed upon debug mode exit as described in cite:[riscv-debug-spec]. When leaving debug mode, the capability in <> is unsealed and written into <>. A debugger may write <> to change where the hart resumes diff --git a/src/hypervisor-integration.adoc b/src/hypervisor-integration.adoc index c7e4e0fd..e996788a 100644 --- a/src/hypervisor-integration.adoc +++ b/src/hypervisor-integration.adoc @@ -131,7 +131,7 @@ The <> register is a renamed extension of <> that is able to hold a capability. Its reset value is the <> capability. As shown in xref:CSR_exevectors[xrefstyle=short], <> is an executable -vector, so it need not be able to hold all possible invalid addresses. +vector, so it does not need to be able to hold all possible invalid addresses (see <>). Additionally, the capability in <> is unsealed when it is installed in <> on execute of an <> instruction. The handling of <> is otherwise identical to <>, but in virtual supervisor mode. diff --git a/src/riscv-hybrid-integration.adoc b/src/riscv-hybrid-integration.adoc index c5f2bbf8..3bd15786 100644 --- a/src/riscv-hybrid-integration.adoc +++ b/src/riscv-hybrid-integration.adoc @@ -317,7 +317,7 @@ the capability stored in <>. A debugger may write <> to change the hart's context. As shown in xref:CSR_exevectors[xrefstyle=short], <> is a data pointer, -so it does not need to be able to hold all possible invalid addresses. +so it does not need to be able to hold all possible invalid addresses (see <>). [#section_cheri_disable] === Disabling CHERI Registers and Instructions @@ -353,12 +353,14 @@ CHERI register access is disabled if The effective CRE for the current privilege is: -* Machine: `mseccfg.CRE` -* Supervisor: `mseccfg.CRE & menvcfg.CRE` -* User: `mseccfg.CRE & menvcfg.CRE & senvcfg.CRE` +* Machine: `<>.CRE` +* Supervisor: `<>.CRE & <>.CRE` +* User: `<>.CRE & <>.CRE & <>.CRE` NOTE: The effective CRE is always 1 in debug mode. +NOTE: On reset CHERI register access is disabled (<>.CRE resets to zero). + Disabling CHERI register access has no effect on implicit accesses or security checks. The last capability installed in <> and <> before disabling CHERI register access will be used to authorize instruction execution and data @@ -370,9 +372,10 @@ Disabling CHERI register access prevents low-privileged {cheri_int_mode_name} so from interfering with the correct operation of higher-privileged {cheri_int_mode_name} software that do not perform <> switches on trap entry and return. -Disable CHERI register access also allows harts supporting CHERI to be fully +Disabling CHERI register access allows harts supporting CHERI to be fully compatible with standard RISC-V, so CHERI instructions, such as <>, that do not change the state of CHERI CSRs raise exceptions when CRE=0. +This is the default behavior on reset. ==== NOTE: xref:cheri_behavior_cre_mode[xrefstyle=short] summarizes the behavior of @@ -530,7 +533,7 @@ NOTE: CRE is not required for the implicit access required by checking memory ac {REQUIRE_HYBRID_CSR} As shown in xref:CSR_exevectors[xrefstyle=short], <> is a data pointer, -so it does not need to be able to hold all possible invalid addresses. +so it does not need to be able to hold all possible invalid addresses (see <>). .Unprivileged default data capability register include::img/ddcreg.edn[] diff --git a/src/riscv-integration.adoc b/src/riscv-integration.adoc index 16054271..a154b1af 100644 --- a/src/riscv-integration.adoc +++ b/src/riscv-integration.adoc @@ -99,7 +99,7 @@ instructions, such as <> or <>, in debug mode. include::img/pccreg.edn[] <> is an executable -vector, so it need not be able to hold all possible invalid addresses. +vector, so it does not need to be able to hold all possible invalid addresses (see <>). [#section_cap_instructions] === Capability Instructions @@ -266,8 +266,9 @@ instruction following the jump is sealed and written to a *c* register. allows unconditional, indirect jumps to a target capability. The target capability is obtained by incrementing the capability in the *c* register operand by the sign-extended 12-bit offset, then setting the -least significant bit of the result to zero. The target capability is unsealed if it is a sentry with zero offset. The capability -with the address of the instruction following the jump is sealed +least significant bit of the result to zero. +The target capability is unsealed if it is a sentry and the instructions has a zero immediate offset. +The capability with the address of the instruction following the jump is sealed and written to a *c* register. All jumps cause CHERI exceptions when a minimum sized instruction @@ -569,7 +570,7 @@ encountered an exception. Otherwise, <> is never written by the implementation, though it may be explicitly written by software. As shown in xref:CSR_exevectors[xrefstyle=short], <> is an executable -vector, so it does not need to be able to hold all possible invalid addresses. +vector, so it does not need to be able to hold all possible invalid addresses (see <>). Additionally, the capability in <> is unsealed when it is installed in <> on execution of an <> instruction. @@ -938,7 +939,7 @@ The <> register is a renamed extension of <> that is able to hold a capability. Its reset value is the <> capability. As shown in xref:CSR_exevectors[xrefstyle=short], <> is an executable -vector, so it need not be able to hold all possible invalid addresses. +vector, so it does not need to be able to hold all possible invalid addresses (see <>). Additionally, the capability in <> is unsealed when it is installed in <> on execution of an <> instruction. The handling of <> is otherwise identical to <>, but in supervisor mode.