RISC-V
Overview
RISC-V is a free and open standard instruction set architecture (ISA) based on reduced instruction set computer (RISC) principles. Public reference material describes it as free and open because its specifications are released under permissive open-source licenses and can be implemented without paying royalties. [citation: RISC-V definition]
A processor-verification paper further describes RISC-V as a free and open ISA defined by the global nonprofit organization RISC-V International. The same source states that a major design goal was to make the ISA suitable for nearly any computing device, and that this goal is reflected in RISC-V's modular design. [citation: RISC-V International and modularity]
ISA configuration in verification examples
The supplied verification evidence uses an RV32I example to show how instruction validity depends on the selected RISC-V configuration. In that example, LWU is described as a pure RV64I instruction and therefore invalid in RV32I, causing an instruction set simulator (ISS) to raise an illegal-instruction exception. The same example shows c.slli x6, 9 raising an illegal-instruction exception when compressed instructions are disabled. [citation: RV32I example and invalid instructions]
This example illustrates that RISC-V verification must account for more than a raw instruction stream: the active ISA configuration, including 32-bit versus 64-bit behavior and whether compressed instructions are enabled, affects whether an instruction is legal. [citation: RV32I example and invalid instructions]
The supplied Ibex leakage-contract paper similarly distinguishes RISC-V register-file configurations. It notes that the Ibex register file can be configured with 32 registers and five index bits for RV32I or with 16 registers and four index bits for RV32E, and that the contract's glitch-decoding logic is compiled with only four index bits when targeting RV32E. [citation: RV32I vs RV32E register-file configurations]
Processor-verification context
RISC-V is a common target for processor-verification research. The cited cross-level verification work lists several RISC-V verification approaches, including semi hand-written directed test suites covering different RISC-V instruction sets, simulation-based generation from randomized patterns or constraint-based specifications, LLVM libFuzzer-based coverage-guided fuzzing for RISC-V ISS verification, and cross-level co-simulation approaches for RTL verification. [citation: RISC-V verification approaches]
An open-source tool, google/riscv-dv, provides a random instruction generator for RISC-V and is used in RISC-V processor verification workflows. [citation: google/riscv-dv random instruction generator]
The same work presents a co-simulation-oriented fuzzing setup in which an ISS and an RTL processor core are fed the same instruction stream and checked for functional mismatches. Because a pipelined RTL core can fetch and complete instructions differently from an ISS, the paper emphasizes comparing architectural register values at appropriate synchronization points, especially after instructions have completed and register values have changed. [citation: ISS RTL comparison]
Translation buffer and endless instruction streams
In the cited fuzzing approach, test vectors are interpreted as arbitrary endless instruction streams. A translation buffer caches already fetched instructions so that the ISS and RTL core receive the same instruction stream despite different fetch behavior. The paper's example uses a 160-bit test vector divided into five 32-bit instruction entries. [citation: Translation buffer]
Execution controller
The cited execution controller has two purposes: preventing infinite loops and detecting mismatches between processor cores. It conservatively detects an infinite loop when a new program-counter address equals an already executed address and register values are unchanged, and it also applies a hard limit of 10,000 ISS instruction executions. For mismatch detection, it compares registers after register-value changes; in the example, an RTL core erroneously executes LWU x8, x0, 48, causing a mismatch against ISS behavior and stopping the simulation. [citation: Execution controller]
Fuzzer mutations
The same paper describes problem-specific mutations for AFL-based fuzzing. Its "Fast Exploration" phase inserts each RISC-V instruction at the beginning of every test vector with source and destination register arguments fixed to x0 and immediate values fixed to 0; the paper gives addi x0, x0, 0 as an example. [citation: Fast Exploration mutation]
Architectural mechanisms: CSRs, traps and exceptions
Public tutorial material on RISC-V describes the machine-mode (M-mode) privilege layer as the foundation of the architecture's trap and operating-system support, implemented through Control and Status Registers (CSRs) and associated trap-handling behavior. [citation: RISC-V M-mode CSRs and traps]
According to that material, key M-mode CSRs and their addresses include:
mstatus(0x300) — global interrupt enable (MIE bit 3), previous interrupt state (MPIE bit 7)mtvec(0x305) — trap handler base address, where the PC jumps on any trapmepc(0x341) — saved program counter of the trapped instructionmcause(0x342) — cause of the trap, with bit 31 indicating interrupt versus exception and bits 30:0 holding the cause codemscratch(0x340) — scratch register for trap-handler softwaremip(0x344) — pending interruptsmie(0x304) — enabled interrupts [citation: RISC-V M-mode CSRs and traps]
The same source states that CSRs are 32-bit registers accessed with dedicated atomic read-modify-write instructions rather than ordinary loads and stores. Three CSR instructions are documented:
- CSRRW rd, csr, rs1 — atomically swap:
rd = CSR; CSR = rs1 - CSRRS rd, csr, rs1 — set bits:
rd = CSR; CSR = CSR | rs1 - CSRRC rd, csr, rs1 — clear bits:
rd = CSR; CSR = CSR & ~rs1[citation: RISC-V CSR instructions]
The tutorial describes the documented trap sequence as follows. When a RISC-V trap occurs, hardware saves the PC into mepc, writes the cause into mcause, clears MIE in mstatus, and jumps to the address in mtvec. Software then reads mcause, handles the event, and executes MRET to return. MRET is described as restoring the PC from mepc, re-enabling interrupts by restoring MIE from MPIE, and returning from the trap handler to the interrupted code. [citation: RISC-V trap sequence]
The same material notes that M-mode is the highest privilege level, and that S-mode (supervisor) and U-mode (user) are additional privilege modes added for operating-system support. [citation: RISC-V privilege modes]
Side-channel security: leakage contracts on the Ibex core
The supplied evidence includes a TCHES 2024 paper, Closing the Gap: Leakage Contracts for Processors with Transitions and Glitches (Haring, Hadžić and Bloem), which applies leakage contracts — formal hardware/software contracts that separate hardware and software verification while ensuring interoperability — to a RISC-V implementation. The paper extends the leakage-contract model to account for glitches and transitions, and presents the first end-to-end verification tool for transient leakage contracts in which hardware and software verification rely on the same contract as a single source of truth, with contracts written in the C programming language. [citation: Leakage contracts for Ibex]
The paper's case study targets the RISC-V Ibex core. It reports that a power contract for Ibex can be written without any modifications to the hardware design, and uses this contract to prove end-to-end security between masked software and gate-level hardware. [citation: Leakage contracts for Ibex]
Glitches and the Ibex register file
In the same paper, glitches are described as ephemeral hardware effects in which transitions in one-hot decoded register indices can cause signals to become unstable and ephemerally propagate unintended register values. The cited worst case is that all registers of the register file can be combined in a single cycle, leaking a combination of the entire register file, for example when switching the register index from x0 to x15 or from x1 to x14, where all index bits transition. The paper emphasizes that x0 is not an actual hardware register but a hardwired zero constant in Ibex, and that each stable register-index bit halves the number of propagated register values. [citation: Ibex register-file glitch model]
The contract distinguishes three kinds of leakages: a common leakage modeling all gates before register writeback, a writeback leakage modeling the remaining leaks from register writeback logic, and a load leakage modeling load values from the memory bus during load instructions. Common and writeback leakages are modeled by a regfile_glitches function called regardless of the instruction; load leakage is modeled by a load_leakage function called only during load instructions. The common leakage uses a glitchy_decode function that forms a mask of index bits that have transitioned from the previous instruction and returns a vector of registers in which each entry either contains the register value or zero if that register is not leaked. [citation: Ibex leakage-contract structure]
Other security research context
Public research context characterizes RISC-V as increasingly important in embedded and IoT settings, where data security and privacy are major concerns. A survey on RISC-V security states that the RISC-V community is studying security solutions aimed at establishing a root of trust and preventing sensitive information on RISC-V devices from being tampered with or leaked. [citation: RISC-V security survey]
RISC-V has also been studied as a target for return-oriented programming (ROP). One cited paper reports that RISC-V ROP can perform Turing-complete computation and arbitrary function calls using gadgets found in a version of GNU libc, and demonstrates a compiler that converts code in a Turing-complete language into RISC-V ROP chains. [citation: RISC-V ROP]
Evidence limitations
The supplied evidence supports RISC-V's identity as a free and open ISA, its definition by RISC-V International, its modularity, RV32I/RV64I and compressed-instruction behavior in a verification example, RV32I/RV32E register-file configuration in the Ibex case study, the documented M-mode CSRs and trap sequence from tutorial material, the use of leakage contracts on the Ibex core including its glitch model, the existence of the google/riscv-dv random instruction generator, and its broader use in verification and security research. It does not provide detailed architectural specifications such as full instruction encodings, the complete privilege-level specification, the memory model, extension ratification status, or standard version history, so those topics are not expanded here.