RISC-V ISA Specification. Version: v0.1-draft.
Adam Zabrocki, Lee Campbell, Martin Maas, RISC-V TEE and J Extension Task Groups
Contributors: Jecel Assumpcao, Allen Baum, Paul Donahue, Greg Favor, Andy Glew, John Ingalls, Christos Kotselidis, Ian Rogers, Josh Scheid, Kostya Serebryany, Boris Shingarov, Foivos Zakkak, Members of the TEE and J Extension Task Groups
RISC-V Pointer Masking (PM) is a feature which provides a possibility of implementing "memory tagging" by ignoring various bits (defined by mask) of the effective address (virtual or physical) on RV128, RV64 and RV32.
Effective address is an address generated by the address generation logic before it is sent to the memory subsystem. As such, there is no special handling of physical vs. virtual memory at the software level.
Memory tagging (MT) is a technique which can significantly improve the memory safety state of any application (including code running in more privileged modes). MT can be fully implemented in the hardware or partially hardware assisted. However, both implementations require a PM feature to be enabled to not overwhelm the performance.
General idea of MT is based on assigning a tag to every granule of memory (a small, e.g. 16-byte, naturally aligned memory region). All accesses to memory must be made via a pointer with the correct tag. Use of an incorrect tag is noted and the monitor software can choose what to do with such a situation (e.g. could be killing the process, or just report it to the user immediately). To be able to store the tag in every memory pointer (poisoning the pointer) and correctly using it in running applications without significant performance impact, PM is necessary.
This document proposes an extension for RISC-V called PM (Pointer Masking) which in the future might be enhanced for implementing a full hardware memory tagging.
We propose to add:
-
new PM configuration CSR register called MMTE (Memory Tagging Extension)
-
new PM pointer masking CSR register for each privilege mode called MPMMASK (Pointer Masking Mask)
-
new PM pointer base CSR register for each privilege mode called MPMBASE (Pointer Masking Base)
Restricted views of the mmte register appear as the smte, vsmte and umte registers in the HS/S-mode, VS-mode and (V)U-mode ISAs respectively.
Each privilege mode has own copy of pointer masking CSR register. It appears as the mpmmask, spmmask, vspmmask and upmmask registers in the M-mode, HS/S-mode, VS-mode and (V)U-mode ISAs, respectively.
Each privilege mode has its own copy of pointer base CSR register. It appears as the mpmbase, spmbase, vspmbase and upmbase registers in the M-mode, HS/S-mode, VS-mode and (V)U-mode ISAs, respectively.
The purpose of the mpmmask register is to be able to precisely define a mask whose bits of the effective address are ignored. The actual address can be calculated by using requested address and mpmmask register.
Additionally, mpmbase register can be defined, allowing to replace those bits of the actual_address which are defined to be masked by mpmmask. mpmbase can be configured to replace only the subset of the masked bits, and the remaining are still ignored and can be used for any purpose (e.g. memory tagging).
If mpmbase register is set (has value other than zero), actual address can be calculated by using requested address, mpmmask and mpmbase register:
actual_address = (requested_address & ~mpmmask) | mpmbasempmbase register can be read-only and hardwired to 0. In such case, the actual address will be calculated only by using requested address and mpmmask register.
When PM extension is enabled, mpmmask and mpmbase registers allow to implement in-process isolation feature. That feature allows for each thread to be isolated to a given block of the address space. It can be used to isolate untrusted code within a process. A high-level concept can be seen on Picture 1.
MMTE layout can be found in Figure 1a, 1b, 1c and 1d for M, HS/S, VS and (V)U-mode.
MPMMASK layout can be found in Figure 2a, 2b, 2c and 2d for M, HS/S, VS and (V)U-mode.
MPMBASE layout can be found in Figure 3a, 3b, 3c and 3d for M, HS/S, VS and (V)U-mode.
Table 1 explains the meaning of PM bits for RV32, RV64 and RV128.
Table 2 explains the meaning of XS bits for RV32, RV64 and RV128.
Table 3 contains the addresses for the xMTE, xPMBASE and xPMMASK CSRs.
Note: Addresses in the Table 3 are preliminary and could be changed during the Opcode and Consistency review.
| mmte[XLEN-1:12] | mmte[11:9] | mmte[8:6] | mmte[5:3] | mmte[2:0] |
|---|---|---|---|---|
WPRI |
M-mode PM |
HS/S-mode PM |
(V)U-mode PM |
XS bits |
| smte[XLEN-1:9] | smte[8:6] | smte[5:3] | smte[2:0] |
|---|---|---|---|
WPRI |
HS/S-mode PM |
U-mode PM |
XS bits |
| vsmte[XLEN-1:9] | vsmte[8:6] | vsmte[5:3] | vsmte[2:0] |
|---|---|---|---|
WPRI |
VS-mode PM |
VU-mode PM |
XS bits |
| umte[XLEN-1:6] | umte[5:3] | umte[2:0] |
|---|---|---|
WPRI |
(V)U-mode PM |
WPRI |
| PM Bits | Name | Meaning |
|---|---|---|
PM[0:0] |
PM.Enabled |
0 – PM is disabled (default) |
PM[1:1] |
PM.Current |
0 – xPMMASK and xPMBASE registers can only be modified by the higher privilege mode (default) |
PM[2:2] |
PM.Instruction |
0 – PM applies to Data accesses only (default) |
| Status | Meaning |
|---|---|
0 |
PM extension is not used (cannot write to any PM CSRs) |
1 |
PM CSRs are writeable but have the initial value (0) |
2 |
Some registers may have non-initial values, but those were saved before (clean) |
3 |
Some registers have unsaved values (dirty) |
| PM CSR name | Address |
|---|---|
MMTE |
0x3c0 |
SMTE |
0x1c0 |
UMTE |
0x4c0 |
VSMTE |
0x2c0 |
MPMMASK |
0x3c1 |
SPMMASK |
0x1c1 |
UPMMASK |
0x4c1 |
VSPMMASK |
0x2c1 |
MPMBASE |
0x3c2 |
SPMBASE |
0x1c2 |
UPMBASE |
0x4c2 |
VPMBASE |
0x2c2 |
| mpmmask[XLEN-1:0] |
|---|
MASK |
| spmmask[XLEN-1:0] |
|---|
MASK |
| vspmmask[XLEN-1:0] |
|---|
MASK |
| upmmask[XLEN-1:0] |
|---|
MASK |
| mpmbase[XLEN-1:0] |
|---|
BASE |
| spmbase[XLEN-1:0] |
|---|
BASE |
| vspmbase[XLEN-1:0] |
|---|
BASE |
| upmbase[XLEN-1:0] |
|---|
BASE |
xMTE register fulfills two-fold function:
-
Can only be programmable by more privileged mode (unless PM.Current bit is enabled)
-
Performs status register function for the current privilege mode
XS bits from MMTE register are only accessible in M, S and VS-mode. XS field encodes the status of Pointer Masking extension in U and VU-mode. These bits can be checked by a context switch routine to quickly determine whether a state save or restore is required. XS field is automatically updated by the hardware when PM CSR registers are modified. Privileged code can directly modify XS bits to restore previously saved XS status (e.g. by the context restore routine). XS bits in M-mode are desired for implementation without S-mode for determining how to perform context switch in U-mode. Otherwise, XS bits in M-mode might mirror XS bits in (V)S-mode or can be hardwired to 0. Additionally, any changes to the PM CSRs affect global XS bits in the mstatus register.
PM bits from MMTE register are accessible in all modes ((V)U/VS/HS/S/M) and can be read to query if the PM feature is currently enforced. By default, only higher privileged code can set the value for PM bits. However, higher privileged code can enable PM.Current bit for lower privileged code. In such scenario, current privilege code has a possibility to self-manage its own configuration of PM bits.
By default, the current CPU mode is using xPMMASK, xPMBASE and PM bits corresponding to it. When CPU is switching the mode, corresponding pair of xPMMASK, xPMBASE and PM bits are used. Special carefulness is necessary when VU and U mode are available. If virtualization extension is enabled, and hypervisor is not using xPMMASK / xPMBASE CSRs for its U-mode then context switches these registers when it context switches between VMs. If a hypervisor is using xPMMASK / xPMBASE CSRs for its U-mode, then it switches in its own pair before dropping down to U-mode. Later, HS/S-mode context switches in the pair for the VM that it returns to.
If higher privileged code needs to use xPMMASK and xPMBASE from the lower privilege mode, there are two possible solutions:
-
Emulate equation 1. purely in software using xPMMASK and xPMBASE CSRs from the desired privilege mode.
-
If PM.Current is enabled it is possible to save the state of the current xPMMASK and xPMBASE CSRs and temporarily replace them with the desired one. At the end, original values can be restored.
MPMMASK register fully two-fold function:
-
Based on PM bits configuration, it can be programmable by the higher privilege mode or by the current privilege mode
-
Performs status register function for the current privilege mode
MPMBASE register fully two-fold function:
-
Based on PM bits configuration, it can be programmable by the higher privilege mode or by the current privilege mode
-
Performs status register function for the current privilege mode
Any write access would be ignored if performed to the current xPMMASK, xPMBASE and MMTE CSR registers and PM.Current is disabled.
PM extension allows various flavors of implementation. If PM is not desired in specific RISC-V mode, appropriate CSRs could be read-only and hardwired to 0.
PM extension does not define the minimum supported maskable bits (it is defined in the profiles). However, there is no upper-bound limitation and XLEN-1 mask can be implemented. Unsupported maskable bits in xPMMASK CSRs are hardwired to 0.
Each privilege level must support the same variation of maskable bits.