RISC-V PMP

The RISC-V ISA is developed through open community discussions. At the time of this writing, one of the most actively-discussed topics is security, and a number of new extensions in this area have been proposed. This page provides an overview of the existing proposals and their current status.

• RISC-V PMP
  • Getting involved
  • Physical Memory Protection (PMP)
    • VexRiscv implementation
  • PMP enhancements (formerly ePMP)
  • Memory Protection Unit (MPU, formerly sPMP)
  • IOPMP
  • Trusted Execution State (TES)

Getting involved

All of the extensions described on this page are discussed in mailing lists and virtual meetings via the RISC-V Foundation. It is free to become a member, either as an individual or as an organization. Once you’re a member, you can join any of the mailing lists. After an extension is sufficiently well-defined and agreed upon, addition to the official ISA is done via pull request on the ISA’s GitHub page.

Physical Memory Protection (PMP)

PMP is configurable in RISC-V’s highest privelege level, machine mode (M), and controls memory access by software running in supervisor (S) and user (U) mode. Small devices may only have M- and U-mode implemented. Machines running Linux, for example, require S-mode, because that is the privilege level which controls the MMU. VexRiscv has a PMP and an MMU plugin, but they are not compatible. Please refer to the RISC-V privileged specification for details.

VexRiscv implementation

A highly optimized implementation of PMP was developed for the VEDLIoT project. This proved challenging because combinatorial logic with many inputs and outputs does not map well to FPGA fabric. In RISC-V, the PMP region bounds are written in an encoded format to the CPU’s control status registers (CSRs). In order to enforce memory restrictions, these must be somehow decoded into a format that can be efficiently compared against memory addresses requested by software. The trivial approach to doing this is to instantiate a decoder, in hardware, for each CSR. Indeed, this is how other open-source implementations have done it (e.g., Rocket, CVA6, NEORV32). The VexRiscv implementation, instead, has a single decoder unit that decodes the CSRs over several CPU cycles when they are modified. This significantly reduces the hardware overhead of the extension.

Limitations The VexRiscv implemenation does not fully comply with the specification, because some features were identified to be of minimal utility for embedded applications and not worth the cost. Specifically:

1. The regions are not ordered by priority. In the specification, the permissions associated with the lowest-numbered PMP CSR that matches the current access are applied. In VexRiscv, permissions are granted if any matching region have them enabled. (E.g., if three matching regions have R–, -W-, and -WX permissions enabled, respectively, the memory access will be granted RWX access.)
2. Only the NAPOT addressing mode is implemented. The minimum granularity is 8 bytes, but this can be made coarser in the configuration file.

PMP enhancements (formerly ePMP)

A number of proposed enhancements to PMP are currently awaiting ratification. The latest draft, at the time of this writing, is avialable here. These changes are motivated by some known vulnerabilities in emedded systems. Please refer to the original document for more information. In a nutshell, the proposal changes the meaning of the LRWX bits in the pmpcfg registers to allow for special permission combinations. These are not very intuitive, because R no longer means “read”, and so forth. The new meanings of those bits are shown in the truth table below:

Memory Protection Unit (MPU, formerly sPMP)

The RISC-V TEE WG is actively discussing, and hoping to finalize, a so-called memory protection unit for RISC-V in 2021. Its former name, supervisor PMP (sPMP), was perhaps more descriptive. The idea is to duplicate PMP, but give control to S-mode software. This scheme allows developers to place an embedded OS in S- instead of M-mode without giving up access to the memory protection hardware required to isolate userspace threads. Then, a security monitor (i.e., hypervisor) can run in M-mode, which uses the existing PMP hardware to separate the OS from TEEs on the same device. The latest revision for RISC-V MPU, as of this writing, is available here. The MPU specification incorporates features of ePMP, which is also on the agenda for finalization ion 2021.

IOPMP

PMP is designed to block access to memory originating from software running on a single core. It does not protect memory from other masters on the system bus, so a new extension has been proposed to handle this. This may be ratified in 2021, based on the latest discussions. See here for an overview.

Trusted Execution State (TES)

Huawei has proposed a TEE extension for RISC-V which is remarkably similar to Arm TrustZone. It is currently marked as inactive on the RISC-V TEE WG, but it is worth noting. A copy has been included in this repository.