Version 0.2-draft-20241218
Smmtt is a RISC‑V Machine mode (M-mode) proposal for providing access control without translation on the physical address space of a system. In this it is similar to PMP, but intended for many more regions than PMP can support. It is based on multilevel tables, similar to the Sv39/Sv48/Sv57 page tables, except only a 2 or 4‑bit access permission is stored at the final level. The current Smmtt proposal uses fixed 3‑level or 2‑level table structures for 4 modes and supports physical address spaces up to 56 bits. This alternative Smmtt proposal makes the table structure more flexible by allowing the M-Mode software to specify the multilevel table structure and supports any physical address space size up 64 bits. For example, it is possible to have a single large table if that is appropriate, based on the amount of physical memory in the system, or one table for main memory and one for I/O space in another use case. Page sizes of 4 KiB, 2 MiB, and 1 GiB are supported by the current Smmtt, but not other sizes that a TLB might support (e.g. via Svnapot).
This proposal outlines an alternative only for RV64. The extension for RV32 and RV128 can be done if others are interested in pursuing this alternative.
Pros
Cons
As in Smmtt, PAW is used to designate the number of bits in a physical address:
63 | 0 | ||||
0 | PA | ||||
64-PAW | PAW |
This extension would be enabled by a bit in the mseccfg CSR.
We start with the assumption that the M-mode software will designate one or more regions of the address space to be subject to access control. Typically this would be the entire PAW-bit physical address space with one structure, but could be handled with two or more structures. Multiple structures would allow access control for different portions of the address space to be changed independently, which might be useful in some situations. A given processor might support 1-8 regions via 1-8 Access Control Match CSRs macm0 to macm7. (Most processors would implement only 1 or 2 macm registers, and their corresponding mact registers.) The format of the macm registers is as follows using a NAPOT encoding of the bits to compare when testing for a match. Each macm register specifies a SDID for caching purposes.
macm registers are WARL. The number of SDID bits can be determined by writing all 1s to bits 7:0 and seeing which read back as 1. An implementation may hardwire the paddr field of the last or only macm register, e.g. to force a match of the entire physical address space.
63 | 11 | 10 | 9 | 8 | 7 | 0 | ||||||||
0 | paddr[PAW−1:12+S] | 2S | L | 0 | SDID | |||||||||
64−PAW | PAW−S | 1+S | 1 | 2 | 8 |
Field | Width | Bits | Description |
---|---|---|---|
SDID | 8 | 7:0 | Supervisor Domain ID |
L | 1 | 10 | Lock |
2S | 1+S | 11+S:11 | NAPOT encoding of physical address region to match |
paddr[PAW−1:12+S] | PAW−S | PAW−1:12+S | Physical address to match |
When bits PAW−1:12+S of a physical address match the same bits of an macm register, then the corresponding mact register specifies a table to use for the access rights. The value of S comes from the NAPOT encoding of macm registers, as the number zero bits starting from bit 11 (i.e., S=0 if bit 11 is 1, S=1 if bits 12:11 are 10, and so on). Setting bits PAW-1:11 to 2PAW-12 (1000–0) causes it to match the entire physical address space. The lowest numbered macm match has priority. If no macm register matches when this extension is enabled in mseccfg, then it is equivalent to no access.
On a match to macmi, the corresponding macti is used to determine access according to the XWR field. If a table lookup is specified, H is set to 12+S and a doubleword is read from {taddr[PAW-1:5+T],PA[H-1:H-T],3'b0}, and H is decremented by T. This process is iterated until a leaf node is reached. The format of mact registers is as follows:
63 | 4 | 3 | 0 | ||||||||
0 | taddr[PAW−1:5+T] | 2T | Type | ||||||||
64−PAW | PAW−T | 1+T | 4 |
Field | Width | Bits | Description | ||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
XWR | 4 | 3:0 |
Permissions/Type with PTE-like encoding:
|
||||||||||||||||||||||
2T | 1+T | 4+T:4 | For XWRs 2, 6, and 14, NAPOT encoding of next or last level table size. For XWRs 0, 1, 3, 4, 5, and 7, this is a Svnapot-like indicator from software that 2T aligned entries of the table have the identical T and XWR field values. | ||||||||||||||||||||||
taddr[PAW−1:5+T] | PAW−T | PAW−1:5+T | Pointer to next or last level table size for XWRs 2, 6, and 14. |
When XWR 2 is used to indicate a next level table, the format of the table entries has the same interpretation as mact above.
For XWRs 0, 1, 3, 4, 5, and 7, the specified access applies to physical addresses matching the high bits PA[PAW-1:H+T]. Thus the T is still used in these entries to implement a Svnapot-like larger region size. This requires software to make 2T aligned entries of the table to have identical T and XWR fields.
The last level table specified by XWR 6 or XWR 14 has an implicit region size associated with each entry given by the number of physical address bits remaining after the bits used to index the table. This region size must be ≥4 KiB. For page sizes >4 KiB, the 4‑bit or 2‑bit access control bits specify access rights for the entire region. If this region size is not supported by a given implementation’s TLB, it should write the next smaller supported page size.
Types 1, 3, 4, 5, and 7 require taddr[PAW-1:5+T] to match the physical address bits PAW-1:5+T to allow a future extension where taddr provides a translation.
The original specification can be completely replicated with a minimal configuration of the proposed specification. The following illustrates how the original fields map to the proposed fields.
One function of the Access Control Match (macm) registers proposed above is very similar to RISC‑V’s existing pmpaddr registers. It may be possible to piggyback on the pmpaddr registers. One possibility is that the Access Control Table (mact) registers are paired with certain pmpaddr registers. If Smmtt is enabled, and the Type field of the (mact) register is not 15, then the Access Control Table architecture described above is used instead of the PMP definition. A separate register for the (SDID) would have to be provided.
63 | 11 | 10 | 8 | 7 | 6 | 5 | 4 | 3 | 1 | 0 | ||||||
paddr[63..12+S] | 2S | RSW | D | A | U | G | XWR | V | ||||||||
52−S | 1+S | 3 | 1 | 1 | 1 | 1 | 3 | 1 |
<webmaster at securerisc.org> | |||
2024-12-18 |