From b96194e198420d63935e729b914738c20fe3a991 Mon Sep 17 00:00:00 2001 From: Franz Fuchs Date: Tue, 26 Nov 2024 13:45:01 +0000 Subject: [PATCH 1/4] Converted summary to American English spellings while reading through --- src/summary.adoc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/summary.adoc b/src/summary.adoc index 5e44155f..d26184b2 100644 --- a/src/summary.adoc +++ b/src/summary.adoc @@ -1,13 +1,13 @@ == Quick Start This document describes the RISC-V extensions for supporting CHERI capabilities in hardware. -Capabilities can be used to provide memory safety, mitigating up to 70% of memory safety issues cite:[msrc-cheri-eval], as well as to provide efficient compartmentalisation. +Capabilities can be used to provide memory safety, mitigating up to 70% of memory safety issues cite:[msrc-cheri-eval], as well as to provide efficient compartmentalization. The extensions are split into the core features required for a working capability system ({cheri_base_ext_name}), and features required to support a mix-and-match of binaries compiled for CHERI and unchanged binaries ({cheri_default_ext_name}). Some other smaller extensions are described that provide additional functionality relevant to CHERI. === Capability Properties -Capabilities are 2*XLEN (which we call CLEN) bit structures, containing all the information required to identify and authorise access to a region of memory. +Capabilities are 2*XLEN (which we call CLEN) bit structures, containing all the information required to identify and authorize access to a region of memory. This includes: * An XLEN bit address, describing where the capability currently points. @@ -46,12 +46,12 @@ This means the following state is added: === Checking Memory -Every memory access performed by a CHERI core must be authorised by a capability. +Every memory access performed by a CHERI core must be authorized by a capability. It is explicitly defined for every instruction where to find the capability to check against. In _purecap_ code, where all pointers are individual capabilities, the capability and address are used together, so e.g. `lw t0, 16(csp)` loads a word from memory, getting the address and bounds from the `csp` register. -For code that has not yet been fully adapted to CHERI (_hybrid_ code), the processor can run in a pointer mode (not to be confused with a privilege mode) where the authorising capability is instead taken from a special CSR: the default data capability (<>). +For code that has not yet been fully adapted to CHERI (_hybrid_ code), the processor can run in a pointer mode (not to be confused with a privilege mode) where the authorizing capability is instead taken from a special CSR: the default data capability (<>). -Instruction fetch is also authorised by a capability: the program counter capability (<>) which extends PC. +Instruction fetch is also authorized by a capability: the program counter capability (<>) which extends PC. This allows code fetch to be bounded, preventing a wide range of attacks that subvert control flow with integer data. Where {cheri_default_ext_name} is supported, the <> also contains the <> indicating whether the processor is running in integer or capability pointer mode. Changing the bounds used for instruction fetch or the pointer mode can be as easy as performing a capability-based jump (<> in capability pointer mode). From 7dc0f621065b07e9e45be42eb26b55485c0bfdfa Mon Sep 17 00:00:00 2001 From: Franz Fuchs Date: Fri, 29 Nov 2024 10:19:34 +0000 Subject: [PATCH 2/4] Minor improvements in summary.adoc --- src/summary.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/summary.adoc b/src/summary.adoc index d26184b2..a710f929 100644 --- a/src/summary.adoc +++ b/src/summary.adoc @@ -38,7 +38,7 @@ This means the following state is added: * Tags in registers, caches, and memory: ** Every register has a one-bit tag, indicating whether the capability in the register is valid to be dereferenced. - This tag is cleared if the register is written as an integer. + Among other reasons, this tag is cleared if the register is written as an integer. ** The tags are also tracked through the memory subsystem: every aligned CLEN-bits wide region has a non-addressable one-bit tag, which the hardware manages atomically with the data. The tag is cleared if the memory region is ever written other than using a capability store from a tagged capability register. @@ -58,7 +58,7 @@ Changing the bounds used for instruction fetch or the pointer mode can be as eas <> and <> instructions are also added to allow cheap mode switching. Exception codes are added for CHERI-specific exceptions on fetch, jumps, and memory access. -No other exception paths are added: in particular, capability manipulations do not trap, but may clear the tag on the result capability if the operation is not permitted. +No other exception paths are added: In particular, capability manipulations do not trap, but may clear the tag on the result capability if the operation is not permitted. === Added Instructions @@ -76,7 +76,7 @@ The added instructions can be split into the following categories: === Existing Instructions -Existing RISC-V instructions are largely unmodified: in {cheri_int_mode_name}, there is binary compatibility. +Existing RISC-V instructions are largely unmodified: In {cheri_int_mode_name}, there is binary compatibility. Instructions that access memory, as well as branches and jumps, are automatically checked against <> and <>, raising an exception if the checks fail. However, <> and <> are reset to <> capabilities, meaning the checks will always pass on systems that have not written to CHERI system registers. From c24c1b25e7cd34f04a1869ddaa169966ec0d6e83 Mon Sep 17 00:00:00 2001 From: Franz Fuchs Date: Fri, 29 Nov 2024 11:30:43 +0000 Subject: [PATCH 3/4] Minor capitalisation fix in introduction --- src/introduction.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/introduction.adoc b/src/introduction.adoc index abacd76b..779cc1c0 100644 --- a/src/introduction.adoc +++ b/src/introduction.adoc @@ -120,7 +120,7 @@ and {cheri_pte_ext_name} are optional extensions in addition to We refer to software as _purecap_ if it utilizes CHERI capabilities for all memory accesses -- including loads, stores and instruction fetches -- rather than integer addresses. Purecap software requires the CHERI RISC-V hart to -support {cheri_base_ext_name}. We refer to software as _Hybrid_ if it uses +support {cheri_base_ext_name}. We refer to software as _hybrid_ if it uses integer addresses *or* CHERI capabilities for memory accesses. Hybrid software requires the CHERI RISC-V hart to support {cheri_base_ext_name} and {cheri_default_ext_name}. From f0116d7dacea0976eab695f5d7746f701a14e7e6 Mon Sep 17 00:00:00 2001 From: Franz Fuchs Date: Fri, 29 Nov 2024 15:32:12 +0000 Subject: [PATCH 4/4] Started improvements in cap-description --- src/cap-description.adoc | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/cap-description.adoc b/src/cap-description.adoc index 94506a8d..1cfa03da 100644 --- a/src/cap-description.adoc +++ b/src/cap-description.adoc @@ -128,8 +128,8 @@ CLEN-bits is cleared. [#c_perm,reftext="C-permission"] Capability Permission \(C):: Allow reading capability data from memory if the -authorising capability also grants <>. Allow writing capability data to -memory if the authorising capability also grants <>. +authorizing capability also grants <>. Allow writing capability data to +memory if the authorizing capability also grants <>. [#x_perm,reftext="X-permission"] Execute Permission (X):: Allow instruction execution. @@ -140,15 +140,15 @@ If a capability grants <> and <>, but no <>, then a cap The rules specified by <> are followed when <> and <> are removed, so additional permissions may also be removed. Clearing a capability's <> and <> allows sharing a read-only version of a data structure (e.g. a tree or linked list) without making a copy. -NOTE: Implementations are allowed to retain invalid capability permissions loaded from memory instead of following the <> behaviour of reducing them to _no permissions_. +NOTE: Implementations are allowed to retain invalid capability permissions loaded from memory instead of following the <> behavior of reducing them to _no permissions_. [#asr_perm,reftext="ASR-permission"] Access System Registers Permission (ASR):: Allow read and write access to all privileged (M-mode and S-mode) CSRs. -If {tid_ext_name} is supported the <>, <>, <>, <>, <>, -<> registers are all considered privileged for the purposes of writing -and unprivileged for reading, and thus require ASR-permission for writes but not reads. -In all cases a suitable privilege mode is required for access. +If {tid_ext_name} is supported the <>, <>, <>, <>, <>, +<>, <>, <> registers are all considered privileged for the purposes +of writing and unprivileged for reading, and thus require ASR-permission for writes but +not reads. In all cases a suitable privilege mode is required for access. [#cap_permissions_encoding] ===== Permission Encoding @@ -295,7 +295,7 @@ references if that SDP bit is set because it "owns" that object. ifdef::cheri_v9_annotations[] WARNING: *CHERI v9:* There is now a 1-bit otype (sentry or unsealed) and the old CHERI v9 otype no longer exists. -The base CHERI-RISC-V standard does not have support for CHERI v9 CSEAL for sealed capabilities with object types and only has CSEALENTRY for sealed entry (sentry) capabilities. +The base CHERI-RISC-V standard does not have support for CHERI v9 CSEAL for sealed capabilities with object types and only has <> for sealed entry (sentry) capabilities. endif::[] This bit indicates the type of the capability: it is a sealed capability if the bit is 1 or unsealed if it is 0. @@ -507,7 +507,7 @@ disambiguate the location of the bounds with respect to an out-of-bounds address R is calculated relative to the base by subtracting 2^MW-2^ from B. If B, T or _a_[E + MW - 1:E] is less than R, it is inferred that they lie in the -2^E+MW^ aligned region above R labelled space~U~ in +2^E+MW^ aligned region above R labeled space~U~ in xref:cap_bounds_map[xrefstyle=short] and the corrections _c~t~_ and _c~b~_ are computed accordingly. The overall effect is that the address can roam 2^E+MW^/4 bytes below