From 043ffcdf73494e1ef25edb08667400bc3077d602 Mon Sep 17 00:00:00 2001 From: Lawrence Esswood Date: Wed, 5 Feb 2025 21:28:10 +0000 Subject: [PATCH 1/3] Changes to pointer masking Change interaction with pointer masking to suggest that it should affect both bounds decode and checks. --- src/ptrmask-integration.adoc | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/src/ptrmask-integration.adoc b/src/ptrmask-integration.adoc index a7ef0d5c..e99b579f 100644 --- a/src/ptrmask-integration.adoc +++ b/src/ptrmask-integration.adoc @@ -1,18 +1,24 @@ [#section_pointer_masking_integration] == Integrating {cheri_base_ext_name} and {cheri_default_ext_name} with Pointer Masking -The pointer masking extensions Smmpm, Smnpm, SSnpm, Sspm and Supm are compatible with {cheri_default_ext_name}. +The pointer masking extensions Smmpm, Smnpm, SSnpm, Sspm and Supm are compatible with both {cheri_base_ext_name} and {cheri_default_ext_name}. +Whenever pointer masking is enabled, all bounds decoding and bounds checks are affected. -For instructions using integer addresses (e.g. loads/stores in {cheri_int_mode_name}), they -are interpreted as being XLEN-wide, and may be subject to pointer masking. -All data accesses are checked against <> which is unaffected by -pointer masking. Therefore no capability bounds encoding is affected. +When bounds are <>, a masked but _not_ sign extended address is used. +Changing how many bits are masked can therefore change the interpretation of the bounds of a capability, +both for the purpose of implicit accesses via bounds checks and any instructions that report the bounds of a capability. +Apart from treating high address bits as 0, there are no other changes to bounds decode, +which are still based on MXLEN, not the new effectively addressable space. +That is, the maximum length of a capability does not change, and +it is not invalid to have a capability that covers a longer range than could be actually be addressed with pointer masking enabled. +(such as one that covers the entire MXLEN address space). +For the <>, both the original and new address +are masked. -For instructions using capabilities (e.g. loads/stores in {cheri_cap_mode_name}), the final access address is subject to pointer masking, but the computed bounds are not. The entire address field, including any bits representing the pointer mask, are used -for bounds calculation. When pointer masking is enabled, the dereferenced address has the masked bits replaced by sign -extension before the bounds check. +NOTE: Because dynamically changing the number of masked bits changes the interpretation of a capability, +software must take the same care when sharing capabilities between address spaces with differing pointer masking +as it generally must when sharing capabilities between address spaces with different page mappings. -NOTE: This scheme doesn't seem very useful, but the problem is the dynamic configuration - of pointer masking which can arbitrarily update the meaning of the address within the capability, - so the full address field must be used to calculate bounds. - There is future work required to determine a more useful way of applying pointer masking to capabilities. +Any address that is checked against a capability (whether via loads/stores in {cheri_int_mode_name} or {cheri_cap_mode_name}), +is also first subject to the same masking as bounds decode (masking without extension). +After any CHERI operations, the final access address is still subject to sign extension as normal. From ca590571d35c361f795747be7ba71c5135c57b7b Mon Sep 17 00:00:00 2001 From: Lawrence Esswood Date: Thu, 13 Feb 2025 19:20:41 +0000 Subject: [PATCH 2/3] Text changes Be clearer about sign extention Mention bounds setting Add a note --- src/ptrmask-integration.adoc | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/ptrmask-integration.adoc b/src/ptrmask-integration.adoc index e99b579f..d4c71700 100644 --- a/src/ptrmask-integration.adoc +++ b/src/ptrmask-integration.adoc @@ -4,6 +4,10 @@ The pointer masking extensions Smmpm, Smnpm, SSnpm, Sspm and Supm are compatible with both {cheri_base_ext_name} and {cheri_default_ext_name}. Whenever pointer masking is enabled, all bounds decoding and bounds checks are affected. +NOTE: The suggestion in this section is based on the pointer masking approach from Morello but with changes +to sign extension and to address the dynamic nature of bit masking. +Further evaluation on RISCV, especially for {cheri_cap_mode_name}, is still required. + When bounds are <>, a masked but _not_ sign extended address is used. Changing how many bits are masked can therefore change the interpretation of the bounds of a capability, both for the purpose of implicit accesses via bounds checks and any instructions that report the bounds of a capability. @@ -14,6 +18,7 @@ it is not invalid to have a capability that covers a longer range than could be (such as one that covers the entire MXLEN address space). For the <>, both the original and new address are masked. +Bounds setting instructions also mask the address in the same way. NOTE: Because dynamically changing the number of masked bits changes the interpretation of a capability, software must take the same care when sharing capabilities between address spaces with differing pointer masking @@ -21,4 +26,4 @@ as it generally must when sharing capabilities between address spaces with diffe Any address that is checked against a capability (whether via loads/stores in {cheri_int_mode_name} or {cheri_cap_mode_name}), is also first subject to the same masking as bounds decode (masking without extension). -After any CHERI operations, the final access address is still subject to sign extension as normal. +After any CHERI operations, the final access address is still subject to as much sign extension as the masking extensions mandate. From 9ac472bea9b49d9100152b60876e1e2141cfd307 Mon Sep 17 00:00:00 2001 From: Alexander Richardson Date: Thu, 13 Feb 2025 14:08:16 -0800 Subject: [PATCH 3/3] Update src/ptrmask-integration.adoc Signed-off-by: Alexander Richardson --- src/ptrmask-integration.adoc | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/ptrmask-integration.adoc b/src/ptrmask-integration.adoc index d4c71700..695fb674 100644 --- a/src/ptrmask-integration.adoc +++ b/src/ptrmask-integration.adoc @@ -14,8 +14,7 @@ both for the purpose of implicit accesses via bounds checks and any instructions Apart from treating high address bits as 0, there are no other changes to bounds decode, which are still based on MXLEN, not the new effectively addressable space. That is, the maximum length of a capability does not change, and -it is not invalid to have a capability that covers a longer range than could be actually be addressed with pointer masking enabled. -(such as one that covers the entire MXLEN address space). +it is not invalid to have a capability that covers a longer range than could be actually be addressed with pointer masking enabled (such as one that covers the entire MXLEN address space). For the <>, both the original and new address are masked. Bounds setting instructions also mask the address in the same way.