From 984b8695e83b79da42d7ee9a6b9c3f6fd64ae69b Mon Sep 17 00:00:00 2001 From: Stefan O'Rear Date: Thu, 7 Mar 2024 22:16:49 -0500 Subject: [PATCH 1/2] SBI binding for CHERI This is considered to be in scope on the theory that this repository already contains patches to various specifications that touch CHERI, and the SBI is an expected part of the supervisor execution environment with the same status as ISA specifications. Permission checks for SBI ecalls are required to support compartmentalization within S-mode. Using ASR, specifically, is a nontrivial design decision with rationale laid out in https://lists.riscv.org/g/sig-cheri/message/68 . Generating a CHERI exception instead of returning a SBI error code makes the behavior consistent with ISA permission checks, improves error location for debugging, and defers committing to purely software permission checks. Using capabilities for hart start and resume avoids requiring the SBI to be able to mint Infinity capabilities at runtime and is expected to simplifiy the implementation. There is an open question whether Zcheri_legacy can be implemented in a way which maintains simultaneous upward compatibility with Zcheri_purecap and the non-CHERI base ISA. The chosen definitions here are not expected to be particularly useful, but avoid introducing new problems. Signed-off-by: Stefan O'Rear --- src/riscv-cheri.adoc | 2 ++ src/riscv-cheri.bib | 15 ++++++++++ src/sbi-integration.adoc | 65 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 82 insertions(+) create mode 100644 src/sbi-integration.adoc diff --git a/src/riscv-cheri.adoc b/src/riscv-cheri.adoc index 293a6a0e..fed108e9 100644 --- a/src/riscv-cheri.adoc +++ b/src/riscv-cheri.adoc @@ -50,6 +50,8 @@ include::riscv-legacy-integration.adoc[] include::riscv-mode-integration.adoc[] +include::sbi-integration.adoc[] + include::instructions.adoc[] include::tables.adoc[] diff --git a/src/riscv-cheri.bib b/src/riscv-cheri.bib index 21c78d03..574b89e3 100644 --- a/src/riscv-cheri.bib +++ b/src/riscv-cheri.bib @@ -65,3 +65,18 @@ @misc{riscv-code-size-spec note = {Version 1.0.4-3}, url = {https://github.com/riscv/riscv-code-size-reduction/releases/download/v1.0.4-3/Zc-1.0.4-3.pdf} } + +@misc{riscv-sbi, + author = {{RISC-V Platform Runtime Services Task Group}}, + title = {RISC-V Supervisor Binary Interface Specification}, + year = {2024}, + note = {Version 2.0}, + url = {https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v2.0/riscv-sbi.pdf} +} + +@misc{riscv-sbi-fwft, + author = {Clément Léger}, + title = {[PATCH v6] Add Firmware Feature extension}, + year = {2024}, + url = {https://lists.riscv.org/g/tech-prs/message/797} +} diff --git a/src/sbi-integration.adoc b/src/sbi-integration.adoc new file mode 100644 index 00000000..2e2049f4 --- /dev/null +++ b/src/sbi-integration.adoc @@ -0,0 +1,65 @@ +[#section_sbi_integration] +== Integrating CHERI extensions with the SBI + +This section describes changes to integrate the SBI (supervisor binary +interface) cite:[riscv-sbi], {cheri_base_ext_name}, and +{cheri_legacy_ext_name}. It must be implemented in a standard-conforming +supervisor execution environment which supports {cheri_base_ext_name} or +{cheri_legacy_ext_name}. + +=== Binary Encoding + +Invocation of SBI functions is only allowed if <> grants <>. If +an `ECALL` instruction is executed with <> that does not grant +<>, the supervisor execution environment generates a CHERI exception. +<> is set as for a forbidden CSR access. + +Unless documented otherwise for a SBI function, the tag and metadata of +arguments to SBI functions are ignored and the tag and metadata of return +values from SBI functions are set to zero. + +The rules for shared memory physical address ranges are not changed; they +continue to be expressed as physical addresses, not capabilities, split between +a pair of registers. + +=== Firmware Features Extension + +NOTE: This extension is not, at the time of writing, merged into the main SBI +specification or ratified; the most recent version is available on the tech-prs +mailing list cite:[riscv-sbi-fwft]. + +The Firmware Features Extension is required to be implemented to support +{cheri_legacy_ext_name}. Two new features are defined. +`CAPABILITY_REGISTER_ENABLE` corresponds to the CRE bit in <>. +`CAPABILITY_MODE_ENABLE` corresponds to the CME bit in <>. +Both are required if {cheri_legacy_ext_name} is supported and default to 0 on +all harts. + +=== Hart State Management Extension + +The `start_addr`, `resume_addr`, and `opaque` parameters of `sbi_hart_start()` +and `sbi_hart_suspend()` are extended to capability type and convey a full +capability to the started or resumed after non-retentive suspend hart. All +registers which are undefined on a newly started hart must not have valid tags. +All registers which are undefined after a non-retentive suspend must either +retain their value, or be set to a value with an invalid tag. + +=== Legacy Extensions + +The `hart_mask` arguments to `sbi_send_ipi()`, `sbi_remote_fence_i()`, +`sbi_remote_sfence_vma()`, and `sbi_remote_sfence_vma_asid()` contain pointers +as seen by S-mode; if S-mode is executing in Capability mode, the hart mask is +a virtual address capability. + +=== Nested Acceleration Extension + +This interaction of this extension with {cheri_base_ext_name} will be defined +as part of the definition of the H extension for {cheri_base_ext_name}. It must +not be implemented until it has been defined. + +=== System Suspend Extension + +The `resume_addr` and `opaque` parameters of `sbi_system_suspend()` are +extended to capability type and convey a full capability to the resumed hart. +All registers which are undefined after a system suspend must either retain +their value, or be set to a value with an invalid tag. From 38f2f703b17f34522bf216cd931771b9f1fd895d Mon Sep 17 00:00:00 2001 From: Stefan O'Rear Date: Sun, 10 Mar 2024 01:01:56 -0500 Subject: [PATCH 2/2] Describe new guidance for ASR Some of this could be moved to an "Extending CHERI RISC-V" section. Signed-off-by: Stefan O'Rear --- src/cap-description.adoc | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/src/cap-description.adoc b/src/cap-description.adoc index 9d0fd428..84738731 100644 --- a/src/cap-description.adoc +++ b/src/cap-description.adoc @@ -74,6 +74,33 @@ Execute Permission (X):: Allow instruction execution. [#asr_perm,reftext="ASR-permission"] Access System Registers Permission (ASR):: Allow access to privileged CSRs. +[NOTE] +==== +<> is used as a catch-all permission for operations on resources +other than virtual memory which require an authorising capability but do not +have a more specific permission. No complete list of such resources can be +given since it may be used for resources defined by future standard extensions, +non-standard extensions, and privileged software. In general, it should be +assumed that <> may allow indirect access to any resource which is +accessible at the current privilege level, but does not allow forging +capabilities. + +The specific resources which <> grants access to depend on the +current privilege level, requiring care when a capability can be accessed from +more than one privilege level. <> is effective only in <>, and +so a capability granting <> may be considered effective only in +privilege levels where at least one page overlapping the capability's bounds is +executable. + +It is recommended that privileged software or extensions which define new +resources use <> to authorise access if the resource affects +execution of existing instructions across <> and traps, delivery of +asynchronous events, or interpretation of virtual addresses. New resources with +more limited effects may use <> for authorisation if fine-grained +access control is unneeded or expected to be performed by unprivileged +software. +==== + ===== Permission Encoding The bit width of the permissions field depends on the value of XLENMAX as shown