From a2888fd8ccd3d2be97e136216c5d505ef40d6ffa Mon Sep 17 00:00:00 2001 From: Alex Richardson Date: Wed, 29 Jan 2025 15:31:05 -0800 Subject: [PATCH 1/5] Clarify unsealing on zero offset in JALR The existing wording was ambiguous since the offset could refer to either the offset of the sentry relative to the base or the instruction's immediate. Co-authored-by: Lawrence Esswood --- src/riscv-integration.adoc | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/riscv-integration.adoc b/src/riscv-integration.adoc index 16054271..59ab5273 100644 --- a/src/riscv-integration.adoc +++ b/src/riscv-integration.adoc @@ -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 From 8f6efa1cf275ac5d025bd114dd9b2fe03db96e60 Mon Sep 17 00:00:00 2001 From: Alex Richardson Date: Wed, 29 Jan 2025 15:34:56 -0800 Subject: [PATCH 2/5] Clarify ambiguous wording of dpcc initialization Clarify that we mean the address of the instruction after debug exit. Co-authored-by: Lawrence Esswood --- src/debug-integration.adoc | 5 ++--- 1 file changed, 2 insertions(+), 3 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 From d9a323721a30883a4d20dbfa1050ac0ec90488fe Mon Sep 17 00:00:00 2001 From: Alex Richardson Date: Wed, 29 Jan 2025 15:50:57 -0800 Subject: [PATCH 3/5] Clarify CRE reset state Add links and clarify that it resets to zero. Co-authored-by: Lawrence Esswood --- src/riscv-hybrid-integration.adoc | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/riscv-hybrid-integration.adoc b/src/riscv-hybrid-integration.adoc index c5f2bbf8..cb3ac01c 100644 --- a/src/riscv-hybrid-integration.adoc +++ b/src/riscv-hybrid-integration.adoc @@ -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 From 7a7374e156c1d2fe8f1d2c3ec06165b4df529dfb Mon Sep 17 00:00:00 2001 From: Alex Richardson Date: Wed, 29 Jan 2025 16:05:31 -0800 Subject: [PATCH 4/5] Add links to the Invalid address conversion section Since this section only appears much later in the document, add a forward reference to help readers. Co-authored-by: Lawrence Esswood --- src/hypervisor-integration.adoc | 2 +- src/riscv-hybrid-integration.adoc | 4 ++-- src/riscv-integration.adoc | 6 +++--- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/hypervisor-integration.adoc b/src/hypervisor-integration.adoc index c7e4e0fd..07d49555 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 need not 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 cb3ac01c..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 @@ -533,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 59ab5273..4ba35174 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 need not be able to hold all possible invalid addresses (see <>). [#section_cap_instructions] === Capability Instructions @@ -570,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. @@ -939,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 need not 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. From c3228cd151d89370d0f52ced9411450b9c58d8b7 Mon Sep 17 00:00:00 2001 From: Tariq Kurd Date: Thu, 30 Jan 2025 11:50:20 +0000 Subject: [PATCH 5/5] Apply suggestions from code review consistent wording Signed-off-by: Tariq Kurd --- src/hypervisor-integration.adoc | 2 +- src/riscv-integration.adoc | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/hypervisor-integration.adoc b/src/hypervisor-integration.adoc index 07d49555..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 (see <>). +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-integration.adoc b/src/riscv-integration.adoc index 4ba35174..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 (see <>). +vector, so it does not need to be able to hold all possible invalid addresses (see <>). [#section_cap_instructions] === Capability Instructions @@ -939,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 (see <>). +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.