diff options
author | wmat <wmat@riscv.org> | 2024-02-29 14:35:52 -0500 |
---|---|---|
committer | wmat <wmat@riscv.org> | 2024-02-29 14:35:52 -0500 |
commit | 497dbc9f75ead61757e153ee041e120c991e16ba (patch) | |
tree | b06cf7815aa1bda67f94d2f396600b39a1d6034d /src/smepmp.adoc | |
parent | b647ef585234b896aa75ff6c8d4147f295e7c44e (diff) | |
download | riscv-isa-manual-497dbc9f75ead61757e153ee041e120c991e16ba.zip riscv-isa-manual-497dbc9f75ead61757e153ee041e120c991e16ba.tar.gz riscv-isa-manual-497dbc9f75ead61757e153ee041e120c991e16ba.tar.bz2 |
Clean up.
Replace note with info as we have no info admonition.
Diffstat (limited to 'src/smepmp.adoc')
-rw-r--r-- | src/smepmp.adoc | 9 |
1 files changed, 5 insertions, 4 deletions
diff --git a/src/smepmp.adoc b/src/smepmp.adoc index c52d77c..547f723 100644 --- a/src/smepmp.adoc +++ b/src/smepmp.adoc @@ -134,12 +134,13 @@ Since PMP rules with a higher priority override rules with a lower priority, loc + An attacker that manages to tamper with a memory region used by S/U mode, even after successfully tricking a process running in M-mode to use or execute that region, will fail to perform a successful attack since that region will be _S/U-mode-only_ hence any access when in M-mode will trigger an access exception. + -[INFO] +[NOTE] ==== In order to support zero-copy transfers between M-mode and S/U-mode we need to either allow shared memory regions, or introduce a mechanism similar to the ``sstatus.SUM`` bit to temporary allow the high-privileged mode (in this case M-mode) to be able to perform loads and stores on the region of a less-privileged process (in this case S/U-mode). In our case after discussion within the group it seemed a better idea to follow the first approach and have this functionality encoded on a per-rule basis to avoid the risk of leaving a temporary, global bypass active when exiting M-mode, hence rendering memory access prevention useless. ==== + -[INFO] + +[NOTE] ==== Although it’s possible to use ``mstatus.MPRV`` in M-mode to read/write data on an _S/U-mode-only_ region using general purpose registers for copying, this will happen with S/U-mode permissions, honoring any MMU restrictions put in place by S-mode. Of course it’s still possible for M-mode to tamper with the page tables and / or add _S/U-mode-only_ rules and bypass the protections put in place by S-mode but if an attacker has managed to compromise M-mode to such extent, no security guarantees are possible in any way. *Also note that the threat model we present here assumes buggy software in M-mode, not compromised software*. We considered disabling ``mstatus.MPRV`` but it seemed too much and out of scope. ==== @@ -153,12 +154,12 @@ To make sure that shared data regions can’t be executed and shared code region For adding _Shared-region_ rules with executable privileges to share code segments between M-mode and S/U-mode, ``mseccfg.RLB`` needs to be implemented, or else such rules can only be added together with ``mseccfg.MML`` being set on *PMP Reset*. That's because the reserved encoding ``pmpcfg.RW=01`` being used for _Shared-region_ rules is only defined when ``mseccfg.MML`` is set, and 4b prevents the adition of rules with executable privileges on M-mode after ``mseccfg.MML`` is set unless ``mseccfg.RLB`` is also set. ==== + -[INFO] +[NOTE] ==== Using the ``pmpcfg.LRWX=1111`` encoding for a locked shared read-only data region was decided later on, its initial meaning was an M-mode-only read/write/execute region. The reason for that change was that the already defined shared data regions were not locked, so r/w access to M-mode couldn’t be restricted. In the same way we have execute-only shared code regions for both modes, it was decided to also be able to allow a least-privileged shared data region for both modes. This approach allows for example to share the .text section of an ELF with a shared code region and the .rodata section with a locked shared data region, without allowing M-mode to modify .rodata. We also decided that having a locked read/write/execute region in M-mode doesn’t make much sense and could be dangerous, since M-mode won’t be able to add further restrictions there (as in the case of S/U-mode where S-mode can further limit access to an ``pmpcfg.LWRX=0111`` region through the MMU), leaving the possibility of modifying an executable region in M-mode open. ==== + -[INFO] +[NOTE] ==== For encoding Shared-region rules initially we used one of the two reserved bits on pmpcfg (bit 5) but in order to avoid allocating an extra bit, since those bits are a very limited resource, it was decided to use the reserved R=0,W=1 combination. ==== |