From 7f30edcd7d1f94985ac4c6100a56b8eaddc37f42 Mon Sep 17 00:00:00 2001 From: Tariq Kurd Date: Wed, 13 Nov 2024 17:01:13 +0100 Subject: [PATCH 1/5] improvements to Zcheripte text --- src/cheri-pte-ext.adoc | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/cheri-pte-ext.adoc b/src/cheri-pte-ext.adoc index edfdaa5a..a8d7070d 100644 --- a/src/cheri-pte-ext.adoc +++ b/src/cheri-pte-ext.adoc @@ -10,9 +10,13 @@ capabilities in memory at the page granularity. For this reason, the {cheri_pte_ext_name} extension adds new bits to RISC-V's Page Table Entry (PTE) format. -Implementing any virtual memory translation scheme (_Sv39_, _Sv48_ or _Sv57_) and {cheri_base_ext_name} requires {cheri_pte_ext_name} to be implemented. +NOTE: There is no explicit mechanism for enabling or disabling {cheri_pte_ext_name}. A VM-enabled legacy (non-CHERI) OS running in {cheri_int_mode_name} will not load or store capabilities, and so the default state of CW=0 causing loaded capabilities to have their tags cleared, and stored capabilities with their tags set to cause a page fault, won't occur. -NOTE: There is no explicit mechanism for enabling or disabling {cheri_pte_ext_name}. A VM-enabled legacy (non-CHERI) OS running in {cheri_int_mode_name} will not load or store capabilities, and so the default state of CW=0 causing loaded capabilities to have their tags cleared, and stored capabilities with their tags set to cause a page fault, won't occur. A CHERI-aware OS running a VM-enabled OS is required to support {cheri_pte_ext_name}, and the minimum level of support is to set CW to 1 in all PTEs and leave <>.CRG and CRG in all PTEs set to 0, which will allow capabilities with their tags set to be loaded and stored successfully. +A CHERI-aware OS running a VM-enabled OS on an RV64 core is required to support {cheri_pte_ext_name}, and the minimum level of support is to set CW to 1 in all PTEs intended for storing capabilities (i.e. anonymous mappings) and leave <>.CRG and CRG in all PTEs set to 0, which will allow capabilities with their tags set to be loaded and stored successfully. + +Therefore Implementing any RV64 virtual memory translation scheme (_Sv39_, _Sv48_ or _Sv57_) and {cheri_base_ext_name} requires {cheri_pte_ext_name} to be implemented. + +NOTE: _Sv32_ (for RV32) does not have any spare PTE bits, and so this extension cannot be implemented. === Limiting Capability Propagation From b996bd91097781dbd14a899ac15ca42a2117c484 Mon Sep 17 00:00:00 2001 From: Tariq Kurd Date: Wed, 13 Nov 2024 17:03:31 +0100 Subject: [PATCH 2/5] move RV64 specifier --- src/cheri-pte-ext.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/cheri-pte-ext.adoc b/src/cheri-pte-ext.adoc index a8d7070d..54481c39 100644 --- a/src/cheri-pte-ext.adoc +++ b/src/cheri-pte-ext.adoc @@ -1,6 +1,6 @@ [#section_sv_cheri] [#cheri_pte_ext] -== "{cheri_pte_ext_name}" Extension for CHERI Page-Based Virtual-Memory Systems +== "{cheri_pte_ext_name}" Extension for CHERI Page-Based Virtual-Memory Systems (RV64 only) CHERI is a security mechanism that is generally orthogonal to page-based virtual-memory management as defined in cite:[riscv-priv-spec]. @@ -12,9 +12,9 @@ format. NOTE: There is no explicit mechanism for enabling or disabling {cheri_pte_ext_name}. A VM-enabled legacy (non-CHERI) OS running in {cheri_int_mode_name} will not load or store capabilities, and so the default state of CW=0 causing loaded capabilities to have their tags cleared, and stored capabilities with their tags set to cause a page fault, won't occur. -A CHERI-aware OS running a VM-enabled OS on an RV64 core is required to support {cheri_pte_ext_name}, and the minimum level of support is to set CW to 1 in all PTEs intended for storing capabilities (i.e. anonymous mappings) and leave <>.CRG and CRG in all PTEs set to 0, which will allow capabilities with their tags set to be loaded and stored successfully. +A CHERI-aware OS running a VM-enabled OS is required to support {cheri_pte_ext_name}, and the minimum level of support is to set CW to 1 in all PTEs intended for storing capabilities (i.e. anonymous mappings) and leave <>.CRG and CRG in all PTEs set to 0, which will allow capabilities with their tags set to be loaded and stored successfully. -Therefore Implementing any RV64 virtual memory translation scheme (_Sv39_, _Sv48_ or _Sv57_) and {cheri_base_ext_name} requires {cheri_pte_ext_name} to be implemented. +Therefore implementing any RV64 virtual memory translation scheme (_Sv39_, _Sv48_ or _Sv57_) and {cheri_base_ext_name} requires {cheri_pte_ext_name} to be implemented. NOTE: _Sv32_ (for RV32) does not have any spare PTE bits, and so this extension cannot be implemented. From 42685e30880e7e1c883c278bea6c43512ae276ef Mon Sep 17 00:00:00 2001 From: Tariq Kurd Date: Thu, 14 Nov 2024 10:10:06 +0100 Subject: [PATCH 3/5] update wording --- src/cheri-pte-ext.adoc | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/cheri-pte-ext.adoc b/src/cheri-pte-ext.adoc index 54481c39..80037945 100644 --- a/src/cheri-pte-ext.adoc +++ b/src/cheri-pte-ext.adoc @@ -12,9 +12,11 @@ format. NOTE: There is no explicit mechanism for enabling or disabling {cheri_pte_ext_name}. A VM-enabled legacy (non-CHERI) OS running in {cheri_int_mode_name} will not load or store capabilities, and so the default state of CW=0 causing loaded capabilities to have their tags cleared, and stored capabilities with their tags set to cause a page fault, won't occur. -A CHERI-aware OS running a VM-enabled OS is required to support {cheri_pte_ext_name}, and the minimum level of support is to set CW to 1 in all PTEs intended for storing capabilities (i.e. anonymous mappings) and leave <>.CRG and CRG in all PTEs set to 0, which will allow capabilities with their tags set to be loaded and stored successfully. +A CHERI-aware OS running a VM-enabled OS is strongly recommended to support {cheri_pte_ext_name}, and the minimum level of support is to set CW to 1 in all PTEs intended for storing capabilities (i.e. anonymous mappings) and leave <>.CRG and CRG in all PTEs set to 0, which will allow capabilities with their tags set to be loaded and stored successfully. -Therefore implementing any RV64 virtual memory translation scheme (_Sv39_, _Sv48_ or _Sv57_) and {cheri_base_ext_name} requires {cheri_pte_ext_name} to be implemented. +Therefore when implementing any RV64 virtual memory translation scheme (_Sv39_, _Sv48_ or _Sv57_) and {cheri_base_ext_name}, implementing {cheri_pte_ext_name} is strongly recommended. + +NOTE: It is possible to detect the presence of {cheri_pte_ext_name} in software, by configuring a page table entry without programming CW and without setting <>.CRG, and testing for an exception on storing a tagged capability. NOTE: _Sv32_ (for RV32) does not have any spare PTE bits, and so this extension cannot be implemented. From 51bbc9e53e52eb7a499644527b2f8502127176be Mon Sep 17 00:00:00 2001 From: Tariq Kurd Date: Thu, 14 Nov 2024 10:26:30 +0100 Subject: [PATCH 4/5] add note about exception handler --- src/cheri-pte-ext.adoc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/cheri-pte-ext.adoc b/src/cheri-pte-ext.adoc index 80037945..d42840f6 100644 --- a/src/cheri-pte-ext.adoc +++ b/src/cheri-pte-ext.adoc @@ -162,7 +162,8 @@ bit value of the capability read. This will introduce additional traps during re ^2^ The choice here follows the pattern of whether to implement the _Svade_ extension to take page-fault exceptions for A and D PTE bit state changes, or whether to implement - a hardware updating mechanism. + a hardware updating mechanism. Software should implement support for a page fault in these cases + which will not be used if the hardware mechanism is implemented. [#xstatus_pte] === Extending the Supervisor (sstatus) and Virtual Supervisor (vsstatus) Status Registers From 3158daa0ebee52267559af63e676628d9eccd63b Mon Sep 17 00:00:00 2001 From: Tariq Kurd Date: Fri, 15 Nov 2024 10:40:47 +0100 Subject: [PATCH 5/5] tie hardware enabling to Svade/Svadu --- src/cheri-pte-ext.adoc | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/src/cheri-pte-ext.adoc b/src/cheri-pte-ext.adoc index d42840f6..8582b3dd 100644 --- a/src/cheri-pte-ext.adoc +++ b/src/cheri-pte-ext.adoc @@ -100,7 +100,7 @@ If the CW bit is clear then: * When CRG is clear, the "no capability state", a store page fault exception is raised when a capability store or AMO instruction is executed and the tag bit of the capability being written is set. -* When CRG is set, the "pre-CW state", two schemes are permitted: +* When CRG is set, the "pre-CW state", two schemes are permitted (also see <>): ** The same behavior as when CRG is clear, allowing software interpretation of this state. @@ -160,10 +160,16 @@ bit value of the capability read. This will introduce additional traps during re It is legal for the implementation to fault even if the tag is not set since this behaviour is only an optimization for software. This means it is also legal to only check the tag under certain conditions and conservatively fault otherwise. -^2^ The choice here follows the pattern of whether to implement the _Svade_ extension - to take page-fault exceptions for A and D PTE bit state changes, or whether to implement - a hardware updating mechanism. Software should implement support for a page fault in these cases - which will not be used if the hardware mechanism is implemented. +^2^ See <>. + +[#section_hardware_pte_updates] +=== Enabling Software or Hardware PTE updates + +The decision about whether to take exceptions on capability stores with the tag set to a page with PTE.CW=0 and PTE.CRG=1 is determined by whether the _Svade_ and _Svadu_ extensions are enabled. +These cause PTE Accessed and Dirty updates to be done in software, via the exception handler, or by a hardware mechanism respectively. + +* If only _Svade_ is implemented, or enabled through henvcfg.ADUE or menvcfg.ADUE, then take a page fault. +* If only _Svadu_ is implemented, or enabled through henvcfg.ADUE or menvcfg.ADUE, then do the hardware update of setting PTE.CW=1 and setting PTE.CRG=<>.CRG as described in <>. [#xstatus_pte] === Extending the Supervisor (sstatus) and Virtual Supervisor (vsstatus) Status Registers