Skip to content

Commit

Permalink
refine the spec according to Qualcomm's comments
Browse files Browse the repository at this point in the history
  • Loading branch information
ybc-alkaid committed Sep 18, 2023
1 parent 2365863 commit 2037917
Show file tree
Hide file tree
Showing 2 changed files with 18 additions and 15 deletions.
Binary file modified rv-spmp-spec.pdf
Binary file not shown.
33 changes: 18 additions & 15 deletions spmp_spec.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -3,12 +3,15 @@

An optional RISC-V S-mode Physical Memory Protection (SPMP) provides per-hart supervisor-mode control registers to allow physical memory access privileges (read, write, execute) to be specified for each physical memory region.
The SPMP is checked before the PMA and PMP checks, the same as paged virtual memory.
The SPMP is also applied to data accesses in M-mode when the MPRV bit in mstatus is set and the MPP field in mstatus contains S or U.

Like PMP, the granularity of SPMP access control settings is platform-specific and, within a platform, may vary by physical memory region. However, the standard SPMP encoding should support regions as small as four bytes.

SPMP checks will be applied to all accesses for U mode and S mode, depending on the values in the configuration registers.
M-mode accesses are not affected and always pass SPMP permission checks.
SPMP registers can always be modified by M-mode and S-mode software. SPMP registers can grant permissions to U-mode, which has none by default and revoke permissions from S-mode, which has all permissions allowed through PMP/ePMP by default.
SPMP registers can always be modified by M-mode and S-mode software.
SPMP can grant permissions to U-mode, which has none by default.
And SPMP can revoke permissions from S-mode, which has all permissions by default (A typical PMP/ePMP usage would give S-mode software access to all addresses via the last PMP entry).

=== Requirements

Expand Down Expand Up @@ -44,10 +47,9 @@ image::RV32_SPMP_address_register_format.svg[title="SPMP address register format
image::RV64_SPMP_address_register_format.svg[title="SPMP address register format, RV64"]

The layout of SPMP configuration registers is the same as PMP configuration registers, as shown in Figure 5. The register is WARL.
The rules and encodings for permission are explained in section 2.4, which resembles the encoding of ePMP (except SPMP does not use locked rules).

. The S bit marks a rule as *S-mode-only* when set and *U-mode-only* when unset.
The encoding of ``spmpcfg.RW=01``, and the encoding ``spmpcfg.SRWX=1111``, now encode a Shared-Region.
The rules and encodings for permission are explained in section 2.4, which resembles the encoding of ePMP (except SPMP does not use locked rules).

. Bit 5 and 6 are reserved for future use.

Expand All @@ -74,26 +76,27 @@ It is the same as PMP/ePMP.
=== Encoding of Permissions


SPMP has three kinds of rules: *U-mode-only*, *S-mode-only*, and *Shared-Region* rules.
The S bit marks a rule as *S-mode-only* when set and *U-mode-only* when unset.
The encoding ``spmpcfg.RW=01`` encodes a Shared-Region and ``spmpcfg.SRWX=1000`` is reserved for future standard use.
SPMP has three kinds of rules: *S-mode-only*, *U-mode-only* and *Shared-Region* rules.
// The S bit marks a rule as *S-mode-only* when set and *U-mode-only* when unset.
// The encoding ``spmpcfg.RW=01`` encodes a Shared-Region and ``spmpcfg.SRWX=1000`` is reserved for future standard use.

. An _S-mode-only_ rule is *enforced* on Supervisor mode and *denied* on User mode.
. An *S-mode-only* rule is *enforced* on Supervisor mode and *denied* on User mode.
+
. A _U-mode-only_ rule is *enforced* on User modes and *denied*/*enforced* on Supervisor mode depending on the value of ``sstatus.SUM`` bit:
. A *U-mode-only* rule is *enforced* on User modes and *denied*/*enforced* on Supervisor mode depending on the value of ``sstatus.SUM`` bit:
+
* If ``sstatus.SUM`` is set, a U-mode-only rule is enforced without code execution permission on Supervisor mode to ensure supervisor mode execution protection.
+
* If ``sstatus.SUM`` is unset, a U-mode-only rule is denied on Supervisor mode.
+
. A _Shared-Region_ rule is enforced on both Supervisor and User modes, with restrictions depending on the ``spmpcfg.S`` and ``spmpcfg.X`` bits:
. A *Shared-Region* rule is enforced on both Supervisor and User modes, with restrictions depending on the ``spmpcfg.S`` and ``spmpcfg.X`` bits:
+
* If ``spmpcfg.S`` is not set, the region can be used for sharing data between S-mode and U-mode, yet not executable. S-mode has RW permission to that region, and U-mode has read-only permission if ``spmpcfg.X`` is not set or RW permission if ``spmpcfg.X`` is set.
+
* If ``spmpcfg.S`` is set, the region can be used for sharing code between S-mode and U-mode, yet not writeable. S-mode and U-mode have execute permission to the region, and S-mode may also have read permission if ``spmpcfg.X`` is set.
+
* The encoding ``spmpcfg.SRWX=1111`` can be used for sharing data between S-mode and U-mode, where both modes only have read-only permission to the region.

+
. The encoding ``spmpcfg.SRWX=1000`` is reserved for future standard use.

The encoding and results are shown in the table:

Expand Down Expand Up @@ -136,9 +139,9 @@ If PMP/ePMP is implemented, accesses succeed only if both PMP/ePMP and SPMP perm

Like PMP entries, SPMP entries are also statically prioritized. The lowest-numbered SPMP entry that matches any byte of access (indicated by an address and the accessed length) determines whether that access is allowed or fails. The SPMP entry must match all bytes of access, or the access fails, irrespective of the S, R, W, and X bits.

1. If the privilege mode of the access is M, the access is allowed;
2. If the privilege mode of the access is S and no SPMP entry matches, the access is allowed;
3. If the privilege mode of the access is U and no SPMP entry matches, but at least one SPMP entry is implemented, the access fails;
1. If the privilege mode of the access is M, the access is ``allowed``;
2. If the privilege mode of the access is S and no SPMP entry matches, the access is ``allowed``;
3. If the privilege mode of the access is U and no SPMP entry matches, but at least one SPMP entry is implemented, the access is ``denied``;
4. Otherwise, the access is checked according to the permission bits in the matching SPMP entry. It is allowed if it satisfies the permission checking with the S, R, W, or X bit corresponding to the access type.

=== SPMP and Paging
Expand All @@ -160,7 +163,7 @@ That means SPMP is enabled when `satp.mode==Bare` and SPMP is implemented.

[NOTE]
====
For satp MODE field, you can refer to Table 4.4 in riscv-privileged spec.
Please refer to Table 4.4 in the riscv-privileged spec for detailed information on the satp.MODE field.
If page-based virtual memory is not implemented, or when it is disabled, memory accesses check the SPMP settings synchronously, so no fence is needed.
====
Expand All @@ -187,7 +190,7 @@ Table of renamed exception codes:

[NOTE]
====
You can refer to Table 3.6 in riscv-privileged spec.
Please refer to Table 3.6 in the riscv-privileged spec for detailed information on exception codes.
====

*Delegation*: Unlike PMP, which uses access faults for violations, SPMP uses SPMP/page faults for violations. The benefit of using SPMP/page faults is that we can delegate the violations caused by SPMP to S-mode, while the access violations caused by PMP can still be handled by machine mode.
Expand Down

0 comments on commit 2037917

Please sign in to comment.