From f0116d7dacea0976eab695f5d7746f701a14e7e6 Mon Sep 17 00:00:00 2001 From: Franz Fuchs Date: Fri, 29 Nov 2024 15:32:12 +0000 Subject: [PATCH] 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