Proposal for Alternative VAkeys

Version 0.2-draft-20231229

Table of Contents

• Table of Contents
• Introduction
• Alternate Proposal
• Design Choices
• Future Work

Introduction

VAkeys is a RISC‑V unpriv or user-mode (which TBD) proposal for providing additional (beyond PMP and paging) access control for loads and stores before translation (if any) of the effective address. It suggests using the high bits of the address to pick one of 256 read permission bits, and one of 256 write permission bits. This alternative allows the software to use bits other than the high bits for permission lookup, but only when other bits of the address match.

This proposal could be used in a mode without address translation (e.g. Machine Mode or when satp.Mode = Bare) or on a processor without translation at all, or it could be used on addresses prior to translation (virtual addresses). To simplify the exposition, this proposal uses virtual address for all of these cases.

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.

This proposal shares a similar mechanism to the Embedded Sandbox proposal, and if pursued, should be unified with that.

RISC-V Glossary

Some acronyms used herein may be unfamiliar as they come from the RISC‑V privileged architecture.
The official RISC‑V ISA specifications may be downloaded from RISC‑V specifications while working versions may be found at the GitHub RISC‑V ISA Manual repository.
The two primary specifications are:

• The RISC-V Instruction Set Manual Volume I: Unprivileged ISA
• The RISC-V Instruction Set Manual Volume II: Privileged Architecture

CSR

An acronym for Control Status Register, a register used to control certain aspects of processor behavior.

NAPOT

An acronym for Naturally Aligned Power-of-2 (Chapter 5 “Svnapot” Standard Extension for NAPOT Translation Contiguity)
NAPOT refers to things of size 2^N bytes being aligned to that size (i.e. the address is a multiple of 2^N, viz. the least significant N bits of the address are zero). In RISC‑V NAPOT sizes are represented with repeated 1s (e.g. in PMP entries) or repeated 0s (e.g. in PTEs) in the lower address bits, then the opposite bit, and then from that point actual address bits, which allows the address and size to encoded in 1 bit more than the address alone. (Note: SecureRISC in the early days had separate address and size fields but changed to adopt this clever bit-saving idea.)

PMP

An acronym for Physical Memory Protection (section 3.7.1 Physical Memory Protection CSRs), which is a mechanism for providing Read, Write, and Execute permission for ranges of physical memory addresses independent of the translation mechanism, and which is logically anded with those permissions.

WARL

An acronym for Write Any Values, Reads Legal Values, which is a CSR characterization that allows processors to implement a subset of the functionality described in a CSR (e.g. by hardwiring certain bits to fixed values).

Alternate Proposal

VAW is used to designate the number of bits in a virtual address:

This extension would be enabled by a bit in the XXX Control Status Register (CSR).

This proposal starts with the assumption that software will designate one or more regions of the virtual address space to be subject to additional access control. For example, when Garbage Collection is used for reclaiming allocated storage, only the heap might be subject to additional protection to implement read or write barriers. Regions are specified using a PMP-like NAPOT matching mechanism. Implementations may support 1-8 regions via 1-8 Virtual Access Control Match CSRs vamatch0 to vamatch7. When a processor implements N vamatchi registers, then it also implements exactly N corresponding vareadil/vareadih and vawriteil/vawriteih pairs. The format of the vamatchi registers is as follows using a NAPOT encoding of the bits to compare when testing for a match.

vamatchi registers are WARL.

When bits VAW−1:12+S of a virtual address match the same bits of vamatchi, then the corresponding vareadil/vareadih and vawriteil/vawriteih pairs specify 128 additional read and write permission bits for the subregions thereof. In particular, on a match to vamatchi, bits 11+S:6+S of the virtual address are used to select bits from the vareadi pair and the vawritei pair. If the vareadi bit is 0, then loads generate an access fault, and if the vawritei bit is 0, then stores generate an access fault. The value of S comes from the NAPOT encoding of vamatchi 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 VAW-1:11 to 2^VAW-12 (1000–0) causes it to match the entire virtual address space. The lowest numbered vamatchi match has priority. If no vamatchi register matches then there is no additional access check.

Design Choices

• Allowing additional permission to extend down to 4096 byte granularity is an arbitrary choice. Larger granularity might reduce the cost by an almost meaningless amount (e.g. 2²⁵ might save one level on NAPOT decoding for Sv57). Smaller granularity is unlikely to be useful, and would extend permissions below a cache line. While cache lines are not today a permission point, there might be a reason someday to have permissions there. Again, the granularity choice is arbitrary for the time being until better principles are uncovered.
• Providing 128 subregion permission bits allows for a graceful extension to RV128. However, for RV32 it would require an expansion of pairs to 4 registers, or a reduction to just 64 subregions.

Future Work

• Obviously user-mode must not be able to restrict the addresses used by more privileged modes. There are multiple ways to address this, and one will need to be specified in the future.

		<webmaster at securerisc.org>
2023-12-29