# RV-Sec5: Enhancing RISC-V Security Evaluation via Targeted ISA-Level Instrumentation using gem5

Muhammad Awais, Maria Mushtaq, Lirida Naviner, Florent Bruguier, Jawad Haj

► To cite this version:

Muhammad Awais, Maria Mushtaq, Lirida Naviner, Florent Bruguier, Jawad Haj. RV-Sec5: Enhancing RISC-V Security Evaluation via Targeted ISA-Level Instrumentation using gem5. 17th Australasian Information Security Conference (AISC 2026), Australasian Computer Science Week (ACSW 2026), Feb 2026, Melbourne, Australia. 10.1145/3793638.3793640. hal-05525254

HAL Id: hal-05525254

https://hal.science/hal-05525254v1

Submitted on 24 Feb 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# RV-Sec5: Enhancing RISC-V Security Evaluation via Targeted ISA-Level Instrumentation using gem5

Muhammad Awais*
COMELEC

Telecom Pairs

Palaiseau, Paris, France

muhammad.awais@telecom-paris.fr

Maria Mushtaq
COMELEC

Telecom Pairs

Palaiseau, Paris, France

maria.mushtaq@telecom-paris.fr

Lirida Naviner
COMELEC

Telecom Pairs

Palaiseau, Paris, France

lirida.naviner@telecom-paris.fr

Florent Bruguier
LIRMM

University of Montpellier

Montpellier, France

florent.bruguier@lirmm.fr

Jawad Haj Yahya
Rivos Inc

Santa Clara, Switzerland

jawadhy@gmail.com

## Abstract

The modularity of the RISC-V Instruction Set Architecture (ISA) has accelerated its adoption in security-critical domains, yet it introduces significant challenges for pre-silicon security validation. Current evaluation methods often rely on high-level emulation that overlooks microarchitectural side effects or post-silicon testing that identifies vulnerabilities too late in the design cycle. This paper presents RV-Sec5, a systematic framework for ISA-level security evaluation that leverages the gem5 simulator. Unlike standard simulators, RV-Sec5 introduces a methodology to map high-level security invariants—such as privilege isolation and memory protection—directly to automated, cycle-accurate instrumentation points within the ISA decoder. This approach bridges the semantic gap between abstract security policies and low-level hardware execution. We demonstrate the framework’s efficacy through a case study involving unauthorized Control and Status Register (CSR) modifications, showing how RV-Sec5 detects privilege escalation attempts and monitors microarchitectural anomalies, such as TLB flushes and cache state changes, in real-time.

## CCS Concepts

* Computer systems organization → Embedded hardware.

## Keywords

RISC-V, gem5, ISA Security, Pre-silicon Validation, Side-channel Profiling, Hardware Security, Embedded Systems, Hardware Attacks, Attacks Simulation.

## ACM Reference Format:

Muhammad Awais, Maria Mushtaq, Lirida Naviner, Florent Bruguier, and Jawad Haj Yahya. 2026. RV-Sec5: Enhancing RISC-V Security Evaluation via Targeted ISA-Level Instrumentation using gem5. In *Australasian Information Security Conference (AISC '26), February 12–13, 2026, Melbourne, VIC, Australia*. ACM, New York, NY, USA, 10 pages. https://doi.org/10.1145/3793638.3793640

<figure><img src="image_2.png" /></figure>

This work is licensed under a Creative Commons Attribution 4.0 International License.
AISC '26, Melbourne, VIC, Australia

© 2026 Copyright held by the owner/author(s).
ACM ISBN 979-8-4007-2282-0/26/02
https://doi.org/10.1145/3793638.3793640

## 1 Introduction

The open-source RISC-V Instruction Set Architecture (ISA) has become a cornerstone for modern computing, offering the modularity required for secure and customizable processor designs. However, as RISC-V expands into security-critical domains such as IoT, edge computing, and aerospace systems, the need for systematic pre-silicon security evaluation has become paramount. Current evaluation methodologies often rely on post-silicon testing or high-level emulation, which frequently fail to capture ISA-specific vulnerabilities or microarchitectural side effects during the early design stages [21].

While cycle-accurate simulators like gem5 [17] are widely used to model hardware-software interactions, existing security evaluation approaches often adopt generic instrumentation strategies. These strategies often lack the semantic awareness required to systematically monitor security-critical ISA behaviors, such as privilege mode transitions, Physical Memory Protection (PMP) configurations, and Control and Status Register (CSR) modifications. This semantic gap limits the ability to uncover vulnerabilities arising from subtle interactions between ISA logic and microarchitectural implementation [9].

In this paper, we present RV-Sec5, a systematic framework for targeted ISA-level instrumentation built on the gem5 simulator. Unlike generic simulation approaches, RV-Sec5 provides a formal methodology to map high-level security invariants, such as "User-mode code cannot modify Machine-mode registers", directly to automated, cycle-accurate interception points within the ISA decoder. By embedding fine-grained probes into the gem5 CPU models, the framework enables real-time monitoring of execution patterns and memory protection enforcement.

To provide a clear boundary for our evaluation, we define a threat model centered on privilege escalation and unauthorized resource access, where an adversary executing code at a lower privilege level (e.g., U-mode) attempts to bypass architectural boundaries.

Our contributions are summarized as follows:

* **A Policy-to-Instrumentation Methodology:** We propose a systematic approach to translate high-level security requirements into specific, decoder-level instrumentation points,
moving beyond ad-hoc engineering efforts to a reproducible verification methodology.

* **RV-Sec5 Framework Architecture:** We introduce a modular framework for gem5 that captures the architectural context (Program Counter, register state, and CSR values) of security-sensitive instructions to enable the detection of privilege escalation and PMP violations.

* **Cross-Layer Event Correlation:** We develop a mechanism to correlate ISA-level instruction events with microarchitectural statistics (TLB flushes, cache hits/misses), allowing for the identification of side-channel leakage paths during pre-silicon validation.

* **Security Invariant Enforcement and Logging:** We implement a rule-based engine that monitors for policy violations during simulation. While the current framework focuses on detection and logging to aid design-time mitigation, it provides the necessary infrastructure for exploring hardware-based runtime enforcement mechanisms.

The remainder of this paper is organized as follows. Section 2 presents the background and related work. Section 3 defines the threat model considered in this study. Section 4 details the proposed methodology for pre-silicon security validation, followed by its instantiation in gem5. Section 6 reports the experimental evaluation. Finally, Section 7 concludes the paper and outlines directions for future research.

## 2 Background and Related Work

The security of RISC-V-based systems emerges from the interaction between the abstract Instruction Set Architecture (ISA) specification and its concrete microarchitectural realization [21]. While the ISA defines architecturally visible behavior and privilege constraints, many security-relevant effects arise from microarchitectural states that are not directly exposed to software [18]. This section reviews the RISC-V privileged architecture from a security perspective and surveys existing pre-silicon security evaluation approaches, highlighting the methodological gap that motivates RV-Sec5.

### 2.1 RISC-V Privileged Architecture and Security Foundations

The RISC-V ISA [21] is a modular, open-standard architecture designed to support extensibility across embedded, general-purpose, and security-critical systems. Its privileged architecture defines a hierarchical execution model consisting of Machine (M), Supervisor (S), and User (U) modes [19], which together enforce isolation between trusted firmware, operating systems, and unprivileged applications.

Core security enforcement in RISC-V relies on a small set of architectural mechanisms, summarized in Table 1. These mechanisms provide a functional baseline for privilege separation and memory isolation. Privilege transitions are mediated by dedicated control-flow instructions (e.g., `ecall`, `mret`) and governed by control bits in the `mstatus` register [21]. Physical Memory Protection (PMP) [6] defines hardware-enforced access permissions over physical memory regions, enabling isolation even in systems without virtual memory. In addition, optional security extensions such as Zk and

Smepmp enhance cryptographic support and strengthen memory protection in trusted execution environments [4].

<table><caption>Table 1: Security-Relevant Components of the RISC-V ISA</caption><thead><tr><td>Component</td><td>Security Role</td></tr></thead><tbody><tr><td>Privilege Mode Transitions [19]</td><td>Enforced through mstatus and trap-related instructions to prevent unauthorized execution across privilege levels.</td></tr><tr><td>Physical Memory Protection (PMP) [6]</td><td>Defines hardware-enforced read, write, and execute permissions for physical memory regions.</td></tr><tr><td>Security Extensions [7]</td><td>Optional extensions (e.g., Zk, Smepmp) providing cryptographic acceleration and enhanced isolation mechanisms.</td></tr></tbody></table>

Although these components define clear architectural rules, the RISC-V specification intentionally abstracts away many microarchitectural structures, including cache hierarchies, branch predictors, and Translation Lookaside Buffers (TLBs) [10]. This abstraction enables implementation flexibility but also creates a semantic gap between architecturally correct execution and microarchitectural behavior. Transient execution attacks such as Spectre [14] and Melt-down [15] exploit this gap by manipulating hidden state transitions that are invisible at the ISA level. As a result, verifying security solely at the architectural level is insufficient to capture a broad class of modern vulnerabilities.

Pre-silicon security validation therefore requires methodologies that connect ISA-level semantics with microarchitectural side effects [8], allowing designers to reason about whether architectural security guarantees hold once implemented in hardware. RV-Sec5 addresses this challenge by extending ISA observability within a cycle-accurate simulation environment, enabling systematic analysis of security invariants before fabrication.

### 2.2 Security-Critical Instructions and Threat Vectors

Within the RISC-V privileged architecture [19], a small subset of instructions and Control and Status Registers (CSRs) [5] exert disproportionate influence over system security. These operations directly modify privilege state, memory protection configuration, or address translation structures, making them high-value targets for adversarial manipulation. Table 2 summarizes representative security-relevant instructions and CSRs.

<table><caption>Table 2: Security-Relevant RISC-V Instructions and CSRs</caption><thead><tr><td>Instruction/CSR</td><td>Function</td><td>Security Relevance</td></tr></thead><tbody><tr><td>CSRRW[5]</td><td>Atomic read/write of CSRs</td><td>Enables direct modification of privilege-related state such as mstatus, potentially leading to privilege escalation.</td></tr><tr><td>SFENCE.VMA[5]</td><td>Flushes TLB entries</td><td>Incorrect or unauthorized use can leave stale translations, enabling memory access violations or covert channels.</td></tr><tr><td>menvcfg[5]</td><td>Configures PMP behavior</td><td>Controls enforcement of physical memory isolation and access permissions.</td></tr><tr><td>DRET[5]</td><td>Return from debug mode</td><td>Improper handling can allow unauthorized transitions between debug and privileged execution.</td></tr></tbody></table>
Attacks targeting these interfaces typically aim at privilege escalation, such as manipulating the mstatus MPP field, or memory corruption, such as bypassing PMP-defined isolation boundaries [6]. Importantly, these violations may occur even when the architectural execution appears correct, as their observable impact can be confined to microarchitectural side effects. RV-Sec5 therefore focuses on these instructions as observation points for detecting deviations from security invariants during simulation.

## 2.3 Simulation Frameworks for Security Evaluation

Pre-silicon security evaluation depends on simulation platforms that balance fidelity and observability. Cycle-accurate simulators such as gem5 [17] provide detailed models of pipelines, caches, and memory systems, making them well suited for microarchitectural security analysis. However, gem5 does not natively expose security-relevant ISA events or privilege semantics, requiring explicit instrumentation to support policy validation.

<table><caption>Table 3: Comparison of RISC-V Simulation Frameworks for Security and Microarchitectural Analysis</caption><thead><tr><td>Simulator</td><td>Model Type</td><td>Security-Relevant Capabilities</td><td>Key Limitations</td></tr></thead><tbody><tr><td>gem5 [17]</td><td>Cycle-accurate, full-system</td><td>Detailed microarchitectural modeling (pipelines, caches, TLBs); extensible event system enabling ISA-level instrumentation and correlation with microarchitectural behavior.</td><td>High complexity and long simulation times for large workloads; no native security policies without instrumentation.</td></tr><tr><td>Spike [2]</td><td>Functional (ISA reference)</td><td>Official RISC-V reference simulator; suitable for ISA compliance checking and differential functional testing.</td><td>No timing model or microarchitectural visibility; unsuitable for side-channel analysis.</td></tr><tr><td>QEMU [3]</td><td>Dynamic binary translation</td><td>Fast user-level and system emulation; useful for OS bring-up and software stack validation.</td><td>Abstracted CPU timing; limited insight into microarchitectural or security-relevant behavior.</td></tr><tr><td>Renode [20]</td><td>System-level co-simulation</td><td>Models heterogeneous SoCs, peripherals, and networks; applicable to firmware and IoT-oriented security studies.</td><td>Non-cycle-accurate CPU abstraction; microarchitectural effects are not modeled.</td></tr><tr><td>Dromajo [13]</td><td>Differential functional simulator</td><td>Supports lockstep co-simulation with RTL for regression testing and functional validation.</td><td>Lacks detailed timing and microarchitectural models.</td></tr><tr><td>Whisper [12]</td><td>Instruction-set simulator (ISS)</td><td>Used in industrial firmware validation workflows, including secure boot testing.</td><td>Limited public documentation; minimal support for microarchitectural analysis.</td></tr><tr><td>Sail-RISCV [22]</td><td>Formal executable specification</td><td>Mathematically precise ISA semantics; enables formal reasoning about security-critical behavior.</td><td>Very slow execution; no support for dynamic execution effects or side-channel analysis.</td></tr></tbody></table>

Other tools listed in Table 3 occupy different points in the abstraction spectrum. Functional simulators such as Spike [2] emphasize ISA compliance but lack timing information, rendering them unsuitable for side-channel analysis. Emulation frameworks such as QEMU [3] offer high performance and ease of use but abstract away most microarchitectural detail. Formal frameworks like Sail-RISCV [22] provide mathematically precise specifications but cannot model dynamic execution effects or enforcement behavior.

## 2.4 Pre-Silicon Security Analysis of RISC-V Systems

Existing research on RISC-V security spans surveys, formal methods, simulation-based analysis, and post-silicon measurement. Gao et al. [8] provide a comprehensive overview of RISC-V security extensions and threats but focus primarily on post-silicon evaluation, which limits the ability to address vulnerabilities early in the design cycle. Formal frameworks, including the RISC-V privileged specification itself [19], precisely define architectural behavior but do not offer mechanisms for dynamic monitoring or validation of enforcement during execution.

Simulation-based approaches offer greater visibility into execution behavior. Prior work has leveraged gem5 to model full-system RISC-V designs and study microarchitectural effects [11]. However, these efforts generally rely on coarse-grained event tracing and lack instruction-level hooks for privileged operations, making it difficult to associate specific ISA events with security policy violations. Conversely, studies of real hardware, such as the work by Gerlach et al. [9], demonstrate the practical relevance of microarchitectural attacks but suffer from limited reproducibility and cannot be applied pre-silicon.

<table><caption>Table 4: Comparison of RISC-V Security Evaluation Approaches</caption><thead><tr><td>Study</td><td>Methodology</td><td>Instrumentation</td><td>Key Limitation</td></tr></thead><tbody><tr><td>Gao et al. [8]</td><td>Survey / Post-silicon</td><td>None</td><td>No early-stage, executable security validation.</td></tr><tr><td>Paul et al. [11]</td><td>gem5 Simulation</td><td>Limited probes</td><td>Insufficient visibility into privileged ISA events.</td></tr><tr><td>Waterman et al. [19]</td><td>Formal specification</td><td>Static verification</td><td>No dynamic enforcement or monitoring.</td></tr><tr><td>Ahmadi et al. [1]</td><td>Theoretical analysis</td><td>None</td><td>No simulation-based validation.</td></tr><tr><td>Gerlach et al. [9]</td><td>Hardware measurement</td><td>Physical probes</td><td>Not applicable pre-silicon.</td></tr><tr><td>RV-Sec5 (Ours)</td><td>Policy-driven methodology</td><td>ISA-level hooks</td><td>Bridges architectural policies and microarchitectural behavior in simulation.</td></tr></tbody></table>

Table 4 summarizes these approaches and contrasts them with RV-Sec5. Rather than proposing another tool-centric solution, RV-Sec5 introduces a methodology for systematically mapping ISA-level security policies to microarchitectural observation points, enabling early-stage validation of enforcement logic.

RV-Sec5 builds on the microarchitectural fidelity of gem5 while introducing a policy-driven methodology for targeted ISA-level observability. Explicitly linking architectural security invariants to microarchitectural events, it enables designers to validate privilege enforcement and detect classes of vulnerabilities that are otherwise difficult to identify prior to hardware fabrication.

## 3 Threat Model

This work targets pre-silicon security validation of RISC-V processors by analyzing whether architectural security invariants are correctly enforced by the microarchitectural implementation. The threat model is intentionally constrained to scenarios that are both
realistic at design time and observable within a cycle-accurate sim-
ulation environment.

**3.1 Adversary Model**

We consider an adversary that controls unprivileged software ex-
ecuting on the target RISC-V system. The adversary may deploy
arbitrary user-mode (U-mode) code [19], including hand-crafted
assembly payloads, with the goal of violating architectural security
guarantees. The attacker is assumed to have no physical access to
the device and no ability to directly modify hardware or firmware
binaries.

Specifically, the adversary is capable of:

* Executing arbitrary U-mode instructions [2], including sequences designed to stress privilege transitions and memory protection mechanisms.

* Attempting illegal Control and Status Register (CSR) accesses, such as writes to mstatus or PMP configuration registers.

* Triggering microarchitectural events (e.g., TLB flushes, speculative execution paths) through architecturally valid but adversarial instruction sequences.

The adversary is *not* assumed to exploit undocumented hardware
bugs or undefined ISA behavior. All attack payloads remain within
the architectural specification but attempt to violate its enforced
security rules.

**3.2 Assets and Security Objectives**

The primary assets protected under this threat model are:

* **Privilege isolation:** Ensuring that unprivileged software cannot escalate execution privileges beyond its assigned mode.

* **Memory isolation:** Preserving the integrity of Physical Memory Protection (PMP) regions and preventing unauthorized memory access.

* **Architectural enforcement integrity:** Ensuring that enforcement of security rules does not introduce unintended microarchitectural side effects that could be exploited as side channels.

Accordingly, the security objectives of this work are to detect:

* Unauthorized modifications of privilege-related CSRs (e.g., mstatus.MPP).

* Illegal PMP configuration changes originating from insufficient privilege levels.

* Anomalous microarchitectural behavior correlated with blocked or illegal ISA-level events.

**3.3 In-Scope Threats**

RV-Sec5 focuses on the following classes of threats, which are
relevant during pre-silicon design validation:

* **Privilege Escalation Attempts:** Architecturally illegal transitions between privilege modes, such as user-mode writes to machine-level CSRs.

* **Memory Protection Violations:** Attempts to weaken or bypass PMP-enforced access permissions.

* **Microarchitectural Side Effects:** Observable timing, cache, or TLB effects that arise from security enforcement logic and could form the basis of side-channel leakage.

The attack patterns considered in this work, including adversarial CSRRW operations targeting mstatus, are intentionally chosen as representative privilege-boundary stress cases. Rather than focusing on the novelty of individual exploits, our contribution lies in formalizing these patterns as an explicit ISA-level attack model for pre-silicon security validation. By systematically exercising specification-defined privilege violations, the methodology evaluates whether a microarchitectural implementation faithfully enforces architectural security invariants under adversarial execution, providing a principled basis for early-stage vulnerability assessment.

**3.4 Out-of-Scope Threats**

The following threat classes are explicitly outside the scope of this
work:

* Physical attacks, including power analysis, electromagnetic leakage, and fault injection.

* Post-silicon attacks requiring direct access to fabricated hardware.

* Hardware Trojans or malicious modifications to the RTL or fabrication process.

* Multi-core coherence attacks and inter-core side channels, which require modeling of shared caches and coherence protocols beyond the single-core focus of this study.

**3.5 Assumptions and Limitations**

We assume that the RISC-V ISA specification represents the intended security contract between software and hardware. RV-Sec5 does not attempt to discover violations of the specification itself, but rather to validate whether a given microarchitectural implementation respects this contract under adversarial execution.

Furthermore, while gem5 provides cycle-accurate modeling of
many microarchitectural components [17], it remains a simulation
framework. As such, results obtained using RV-Sec5 are intended
to inform design-time security validation and should be comple-
mented by RTL-level verification and post-silicon testing.

Under these assumptions, RV-Sec5 enables systematic, pre-silicon
evaluation of whether architectural security invariants are enforced
correctly and without introducing exploitable microarchitectural
side effects.

**4 Methodology**

RV-Sec5 proposes a methodology for pre-silicon security validation of RISC-V processors by systematically connecting architectural security invariants with observable microarchitectural behavior. The methodology defines how existing architectural rules can be validated against their microarchitectural realization using cycle-accurate simulation the work flow of our methodology is shown in Figure 1.

The methodology follows a structured, execution-driven work-
flow in which security-sensitive application code is first compiled
using the RISC-V toolchain and executed under the gem5 simula-
tion. Afterward, targeted ISA-level interception captures privileged
<figure><img src="image_3.png" /><figcaption>Figure 1: RV-Sec5's targeted ISA-level observability framework, enabling cycle-accurate correlation of privileged RISC-V instructions with microarchitectural behavior to validate architectural security invariants in pre-silicon simulation.</figcaption></figure>

and memory-management instructions at decode and execution time. These intercepted events are then correlated with microarchitectural state (e.g., MMU, PMP, and cache behavior) and analyzed through policy checking and profiling to assess compliance with architectural security invariants and to expose potential side effects observable during adversarial execution.

## 4.1 Security Invariant Specification

The foundation of the methodology is the explicit definition of security invariants derived from the RISC-V privileged architecture specification [19]. An invariant represents a rule that must hold for all architecturally correct executions, regardless of microarchitectural implementation.

Examples of such invariants include:

* Unprivileged (U-mode) [19] software must not modify machine-level CSRs, such as mstatus or PMP configuration registers [6].

* Updates to address translation structures must respect privilege ordering and architectural fencing rules.

* Transitions into or out of privileged execution modes must occur only via architecturally defined control-flow mechanisms.

These invariants are manually derived from the specification and represent the intended security contract between software and hardware. RV-Sec5 does not claim completeness of invariant coverage; instead, it provides a systematic mechanism to validate whether selected invariants are respected during execution.

## 4.2 ISA-Level Event Observation Model

Given a set of security invariants, the next step is to identify architectural events whose execution may affect invariant satisfaction. RV-Sec5 focuses on security-sensitive ISA events, defined as instructions or architectural state updates that directly influence privilege level, memory isolation, or address translation.

The methodology observes:

* CSR access events that modify privilege or protection state.

* Address translation synchronization events that affect TLB state.

* Control-flow events governing privilege transitions.

For each observed event, the methodology records a minimal architectural execution context consisting of:

* The program counter identifying the event origin.

* The active privilege mode at the time of execution.

* The architectural state being modified (e.g., CSR identifier and value).

This observation layer is purely architectural: it captures what event occurred and under which privilege context, without embedding any enforcement logic or implementation-specific assumptions.

## 4.3 Post-Execution Policy Compliance Analysis

Following program execution, recorded ISA-level events are evaluated against the predefined security invariants. This analysis determines whether any event violates an invariant, such as an illegal privilege escalation attempt or an unauthorized modification of a protected state.

Policy compliance checking is deterministic and specification-driven. Each logged event is matched against invariant predicates (e.g., "U-mode → no write to mstatus"), and violations are flagged accordingly. Importantly, this stage does not alter execution behavior; it validates whether the observed behavior conforms to architectural security rules.

The output of this stage is a structured violation trace that links invariant violations to the exact architectural event and execution context in which they occurred.

## 4.4 Microarchitectural Side-Channel Analysis

Beyond architectural correctness, RV-Sec5 evaluates whether security-relevant events introduce observable microarchitectural side effects that could be exploited as side channels. This analysis is based on correlating architectural event traces with microarchitectural performance metrics collected during execution.
Side-channel analysis in this methodology is defined as follows:

A security mechanism preserves *side-channel integrity* if blocking or handling an architecturally illegal event does not introduce distinguishable microarchitectural behavior relative to a legal execution path.

The methodology compares microarchitectural statistics—such as cache activity, TLB behavior [10], and pipeline stalls—across compliant and violating executions to identify anomalous patterns. This correlation enables early detection of enforcement-induced leakage risks without assuming any specific attack model.

## 4.5 Methodological Scope and Integration

The methodology is designed to support automated and repeatable evaluation during early design stages. Representative test programs, including adversarial instruction patterns, are used to systematically exercise architectural security invariants under controlled execution. RV-Sec5 focuses on validating whether a given implementation adheres to the security guarantees defined by the RISC-V privileged specification [19] by combining ISA-level observability with microarchitectural correlation [21]. In doing so, it provides a principled and execution-driven approach for design-time assessment of privilege and isolation properties in RISC-V systems.

## 5 Implementation in gem5

This section describes how the RV-Sec5 methodology is instantiated within the gem5 simulator [16]. The implementation realizes the architectural event observation and logging mechanisms required by the methodology, but does not introduce new security enforcement mechanisms. Instead, it enables systematic validation of whether architectural security invariants are respected by the simulated microarchitecture.

The implementation is structured to reflect the methodological stages introduced in Section 4: (i) observation of security-relevant ISA events, (ii) capture of architectural execution context, and (iii) exposure of these events for post-execution policy and side-channel analysis.

### 5.1 Implementation Overview

gem5[16] is a cycle-accurate, event-driven simulator that supports extensible ISA definitions and microarchitectural models. RV-Sec5 leverages this extensibility to observe selected security-sensitive ISA events [8] without altering functional execution semantics.

The implementation introduces three core components:

* **ISA-level event interception**, used to identify execution of security-sensitive instructions.

* **Context capture at commit time**, ensuring architectural accuracy of observed events.

* **Structured event logging**, enabling offline policy compliance and side-channel analysis.

These components collectively implement the observation model required by the methodology while remaining agnostic to specific security policies.

### 5.2 ISA-Level Event Interception

To observe security-relevant architectural events, RV-Sec5 instruments the RISC-V ISA decoding and execution flow within gem5 [17]. The implementation identifies instructions that may affect privilege state [16], memory protection configuration, or address translation behavior, such as CSR access [5] instructions and address translation synchronization operations. When such an instruction

<figure><img src="image_4.png" /><figcaption>Figure 2: Targeted ISA-level interception in gem5's RISC-V decoder, showing how privileged CSRRW operations are identified and augmented with security logging to enable cycle-accurate observability of architectural state changes.</figcaption></figure>

is decoded, the implementation marks it as security-relevant and associates it with a lightweight observation hook. This hook does not modify instruction behavior or execution order; it merely signals that an architectural event of interest has occurred. Figure 2 illustrates this interception conceptually. The figure is provided for clarity and does not represent a required architectural modification.

### 5.3 Architectural Context Capture

For each observed ISA-level event, RV-Sec5 captures a minimal architectural execution context sufficient for security analysis. Context capture occurs at instruction commit to ensure that only architecturally retired behavior is recorded.

The captured context includes:

* The program counter (PC) [21] identifying the origin of the event.

* The active privilege mode at the time of execution.

* The architectural resource being accessed or modified (e.g., CSR identifier [5]).

* The old and new architectural values, where applicable.

<figure><img src="image_5.png" /><figcaption>Figure 3: Security probe point added to gem5's BaseCPU for privileged instruction observability.</figcaption></figure>

This context reflects the architectural state visible to software and avoids dependence on simulator-internal or speculative pipeline state. Figure 3 illustrates how commit-stage observation is realized within gem5's CPU model.
## 5.4 Logging and Event Export

Captured events are forwarded to a dedicated logging component, referred to as the SECURITY_LOGGER. The logger records events in a structured format that preserves temporal ordering and execution context while remaining independent of any specific security policy.

<figure><img src="image_6.png" /><figcaption>Figure 4: CSR-aware security probe integrated into gem5's TimingSimpleCPU.</figcaption></figure>

Importantly, the logger performs no filtering, blocking, or enforcement actions. Its role is purely observational, enabling deterministic replay and analysis of security-relevant execution traces after simulation. Figure 4 illustrates how commit-stage events are forwarded to the logging infrastructure without disrupting pipeline timing or simulator fidelity.

## 5.5 Simulation Configuration and Workflow Integration

RV-Sec5 integrates with gem5's hybrid configuration model, combining Python-based system configuration with C++-level observation hooks. Simulation scripts specify which classes of ISA events should be observed and enable or disable logging components as needed.

<figure><img src="image_7.png" /><figcaption>Figure 5: gem5 Python configuration for registering a CSR security probe listener.</figcaption></figure>

This separation allows the same microarchitectural model to be evaluated under different security analysis configurations without recompilation. Figure 5 illustrates an example configuration workflow used to enable CSR event logging during simulation.

The resulting execution traces are consumed by offline analysis tools implementing the policy compliance and side-channel correlation stages described in Section 4. This design supports repeatable evaluation and integration into automated regression testing pipelines.

## 5.6 Design Rationale and Limitations

The implementation intentionally avoids embedding security policies or mitigation logic within the simulator. Instead, it focuses on exposing architecturally meaningful execution events with sufficient fidelity to support external analysis.

This design choice ensures that:

* Observed behavior reflects the intended architectural contract rather than simulator-specific enforcement.

* Security analysis remains reproducible and independent of implementation details.

* The same methodology can be applied to alternative simulation platforms or extended to RTL-level validation.

As with all simulation-based approaches, the implementation inherits the limitations of the underlying simulator [16]. While gem5 provides detailed microarchitectural models, it cannot capture all physical effects present in fabricated hardware. RV-Sec5 is therefore intended as a complementary pre-silicon validation mechanism rather than a replacement for RTL verification or post-silicon testing.

# 6 Evaluation

This section evaluates RV-Sec5 as a pre-silicon security validation methodology. The goal is twofold: (i) demonstrate that ISA-level security-relevant events can be observed and attributed to a precise architectural context, and (ii) show that these event traces can be used to validate compliance with privileged-architecture invariants and to assess whether handling of violating events introduces distinguishable microarchitectural side effects.

## 6.1 Experimental Setup

All experiments are performed using a single-core RISC-V configuration in gem5 [16]. Unless stated otherwise, the system provides User (U) and Machine (M) privilege modes and includes Physical Memory Protection (PMP) with 16 configurable regions. We run controlled microbenchmarks and adversarial payloads compiled for RV64GC [21].

<figure><img src="image_8.png" /><figcaption>Figure 6: Adversarial RISC-V assembly payload triggering an illegal mstatus write from User mode.</figcaption></figure>

Adversarial payloads as specification-violating tests. The payload in Figure 6 is intentionally designed to violate the RISC-V privileged specification by attempting to write mstatus.MPP from U-mode. We do not claim this program constitutes a novel exploit; rather, it is a specification-violating test case used to validate whether the simulated design correctly implements the intended architectural privilege rules under adversarial execution, consistent with the threat model in Section 3.

## 6.2 Metrics and Data Collected

The evaluation uses two classes of measurements:

Architectural event trace. For each security-relevant ISA event (e.g., CSR access, privilege transition, address-translation synchronization), RV-Sec5 records: (i) program counter, (ii) active privilege
mode, (iii) target resource (CSR / event type), and (iv) pre/post values where applicable.

*Microarchitectural statistics.* To assess side-channel-relevant effects, we collect microarchitectural counters from gem5 over the same execution windows, including cache activity (hits/misses), TLB statistics, and pipeline stall cycles. These statistics are used only for *correlation* with architectural events and not as proof of exploitability.

## 6.3 Invariant Compliance: Detecting a Privilege Violation

We first evaluate whether the methodology detects a clear violation of the invariant: *U-mode software must not modify machine-level privileged CSRs such as mstatus*.

During execution of the test payload in Figure 6, RV-Sec5 records an attempted write to mstatus at PC 0x8001012c while executing in U-mode. Table 5 summarizes the recorded context.

<table><caption>**Table 5: Recorded context for a specification-violating CSR write attempt.**</caption><thead><tr><td>Metric</td><td>Value</td></tr></thead><tbody><tr><td>Target CSR</td><td>mstatus</td></tr><tr><td>Offending PC</td><td>0x8001012c</td></tr><tr><td>Requested privilege state</td><td>MPP=0x3 (Machine)</td></tr><tr><td>Current privilege state</td><td>priv=0x0 (User)</td></tr><tr><td>Outcome in simulation</td><td>Illegal write flagged (trap/exception path taken)</td></tr></tbody></table>

*Interpretation.* This result demonstrates the core capability required by the methodology: RV-Sec5 attributes an illegal privilege-state modification attempt to a concrete architectural context (PC and privilege mode) and emits an explicit violation record. The simulation outcome (trap/exception handling) is used to validate that the modeled system responds according to the privileged specification.

## 6.4 Coverage of Security-Relevant Event Classes

To support broader security validation beyond CSR writes, RV-Sec5 implements observation hooks for three security-relevant event classes: (i) CSR modifications, (ii) address-translation synchronization events, and (iii) memory protection configuration updates. Table 6 summarizes the implemented event channels and their intended analytical role.

<table><caption>**Table 6: Event observation channels implemented for security validation.**</caption><thead><tr><td>Channel</td><td>Target</td><td>Analytical Role</td></tr></thead><tbody><tr><td>ppSecurityInstr</td><td>CSR instructions</td><td>Record privileged CSR accesses with PC and privilege context to validate invariant compliance.</td></tr><tr><td>ppTLBAccess</td><td>SFENCE.VMA</td><td>Record translation synchronization events for analyzing ordering and potential abnormal flush patterns.</td></tr><tr><td>ppMemoryAccess</td><td>PMP-related CSRs</td><td>Record PMP configuration updates for validating memory isolation invariants.</td></tr></tbody></table>

These event classes correspond to architectural interfaces that commonly mediate privilege and isolation boundaries in RISC-V systems. While the evaluation focuses on controlled microbenchmarks, the same event classes appear in realistic firmware and OS code paths (e.g., trap handling, TLB shootdowns, PMP initialization). We therefore treat these tests as *unit-level security validation* of enforcement logic.

## 6.5 Side-Channel Correlation Analysis

The evaluation includes a correlation analysis to examine the relationship between specification-violating ISA events and microarchitectural behavior. The goal is to assess whether executions that trigger architectural violations exhibit observable differences in microarchitectural activity when compared to compliant executions with comparable instruction sequences.

Two execution scenarios are analyzed: a compliant baseline that executes without illegal CSR operations, and a violating execution in which an unauthorized CSR write follows the architecturally defined trap or exception path. For both cases, microarchitectural statistics—such as cache activity, TLB behavior, and pipeline stalls—are collected over a fixed execution window aligned with the observed ISA-level event.

The resulting traces, illustrated in Figures 7 and 8, enable direct inspection of microarchitectural behavior in the vicinity of security-relevant events. Under the evaluated configuration and workloads, the analysis shows consistent behavior between compliant and violating executions, indicating that architectural handling of the violating event does not introduce pronounced microarchitectural side effects. This capability demonstrates how RV-Sec5 supports systematic examination of execution behavior and provides a foundation for broader side-channel analysis across additional workloads and system configurations.

## 6.6 Logger Analysis

This subsection reports the results obtained from RV-Sec5's execution tracing and offline analysis pipeline. Consistent with the threat model (Section 3), the objective is *validation*: (i) attribute security-relevant ISA events to an architectural context (PC, privilege mode, target CSR), (ii) flag specification-violating events deterministically, and (iii) quantify whether handling a violating event introduces a distinguishable microarchitectural footprint under the evaluated workload.

*Architectural event attribution.* During execution of the specification-violating CSR payload (Figure 6), the logger records a CSR write attempt targeting mstatus at PC=0x8001012c. The event is timestamped at Cycle=502300 and is associated with U-mode execution. Figure 7 visualizes the temporal localization of this event within the observation window: the trace shows repeated CSR accesses over cycles 502000–502300 and highlights the single unauthorized mstatus write attempt at cycle 502300.

*Violation record produced by offline checking.* The post-execution compliance checker evaluates each logged event against the corresponding invariant (e.g., “U-mode → no writes to mstatus”). For the offending CSR write attempt, the checker produces the following structured record:
<figure><img src="image_9.png" /><figcaption>Figure 7: Timeline of security-relevant CSR accesses, highlighting the unauthorized mstatus write aligned to simulation cycles.</figcaption></figure>

[SECURITY] Cycle 502300:

CSR_WRITE @ PC=0x8001012c

- CSR: mstatus (0x300)

- Privilege: U-mode

- Requested update: MPP <- 0x3

- Result: violation flagged; trap/exception path taken

We intentionally avoid interpreting the simulator's trap behavior as a new "runtime enforcement" mechanism provided by RV-Sec5. Instead, the trace and the trap/exception outcome are used to validate that the simulated design follows the privileged-architecture contract for illegal CSR writes.

<figure><img src="image_10.png" /><figcaption>Figure 8: Access-control outcomes for privileged CSRs and memory resources during evaluation.</figcaption></figure>

*Access-control outcomes across resources.* Figure 8 aggregates access outcomes (Allowed vs. Blocked) across the monitored resources. The results indicate that access-control decisions are selective: mstatus exhibits both allowed and blocked events, while PMP configuration (pmpcfg0) accesses are allowed under the observed workload. This is consistent with expected system behavior, where PMP initialization is performed by trusted M-mode code (e.g., early boot), whereas unprivileged attempts to modify machine-level CSRs are flagged as violating.

*Microarchitectural Correlation (Side-Channel Analysis).* A key contribution of this work is the ability to directly correlate security-relevant ISA events with microarchitectural behavior at cycle granularity. For the evaluated case, we align the violating CSR write event (centered at cycle 502300) with detailed microarchitectural traces, including cache activity, TLB behavior, and pipeline stalls. This correlation enables precise inspection of the microarchitectural response to specification-violating events and clearly separates architecturally mandated control-flow effects from unintended side effects. In the examined configuration and workload, the traces show that handling the violating CSR operation follows the expected architectural control path without introducing additional observable microarchitectural behavior. This result demonstrates the effectiveness of RV-Sec5 in exposing and analyzing potential side-channel-relevant effects at the ISA-microarchitecture boundary.

## Takeaway

The evaluation demonstrates that the proposed methodology enables precise observation and validation of security-relevant ISA events in a pre-silicon setting. In particular, the results show that:

* **Accurate attribution of privileged CSR events:** Specification-violating attempts to modify mstatus from User mode are consistently detected and attributed to a precise architectural context, while legitimate Machine-mode accesses are correctly identified as compliant.

* **Correct differentiation of trusted PMP updates:** All observed pmpcfg0 and pmpaddrN updates originate from trusted Machine-mode code paths and are recorded without false violation reports.

* **No disruption of architectural execution:** Instruction fetches, loads, and stores execute as expected under the evaluated workloads, indicating that the observation and logging mechanisms do not interfere with functional behavior.

Together, these findings indicate that RV-Sec5 provides a low-overhead methodology for design-time validation of architectural security invariants, supporting early detection and analysis of privilege-boundary violations in simulation.

## Future Work and Limitations

The current study focuses on a limited set of privileged CSRs, primarily mstatus and PMP-related registers, and evaluates controlled, specification-violating test cases on a single-core, out-of-order RISC-V configuration in gem5. As such, the results do not capture the full complexity of multi-core systems, in-order pipelines, or large operating-system workloads.

Future work will extend the methodology to additional architectural mechanisms, including delegation registers (e.g., medeleg) and address translation state (e.g., satp), as well as to multi-core configurations with shared caches. We also plan to integrate automated adversarial payload generation and complementary techniques such as fuzzing and formal analysis to improve coverage of corner cases. Finally, ongoing efforts aim to align the simulation-based methodology with RTL-level validation and hardware testing to assess its applicability beyond the pre-silicon stage.
# 7 Conclusions

This work introduced RV-Sec5, a methodology for pre-silicon security validation of RISC-V processors that leverages targeted ISA-level observability within cycle-accurate simulation. RV-Sec5 systematically exposes security-relevant architectural events—such as privileged CSR accesses, address-translation synchronization, and memory protection configuration—and analyzes them in their precise execution context to validate compliance with the RISC-V privileged specification. The evaluation shows that specification-violating behavior, including unauthorized attempts to modify mstatus from User mode, can be consistently identified and distinguished from legitimate Machine-mode activity, while benign operations such as trusted PMP configuration updates and normal memory accesses are observed without false violation reports. In addition, correlating ISA-level events with microarchitectural statistics provides a structured basis for examining whether the handling of violating events introduces observable side effects, supporting early-stage analysis relevant to side-channel considerations. By bridging architectural intent and simulated microarchitectural behavior, RV-Sec5 complements formal verification and post-silicon testing and helps designers reason about privilege-related vulnerabilities earlier in the RISC-V processor development cycle.

# References

[1] Mahya Morid Ahmadi, Faiq Khalid, and Muhammad Shafique. 2021. Side-channel attacks on risc-v processors: Current progress, challenges, and opportunities. arXiv preprint arXiv:2106.08877 (2021).

[2] Joao Pedro Rosa Baptista. 2023. RISC-V Streaming Extension Support on the Spike Simulator. (2023).

[3] Fabrice Bellard. 2005. QEMU, a fast and portable dynamic translator. In USENIX annual technical conference, FREENIX Track, Vol. 41. California, USA, 10-5555.

[4] Davide Bove and Julian Funk. 2023. Basic secure services for standard RISC-V architectures. Computers & Security 133 (2023), 103415.

[5] Niklas Bruns, Vladimir Herdt, Daniel Große, and Rolf Drechsler. 2021. Toward RISC-V CSR Compliance Testing. IEEE Embedded Systems Letters 13, 4 (2021), 202-205. doi:10.1109/LES.2021.3077368

[6] Kevin Cheang, Cameron Rasmussen, Dayeol Lee, David W Kohlbrenner, Krste Asanović, and Sanjit A Seshia. 2022. Verifying risc-v physical memory protection. arXiv preprint arXiv:2211.02179 (2022).

[7] Enfang Cui, Tianzheng Li, and Qian Wei. 2023. Risc-v instruction set architecture extensions: A survey. IEEE Access 11 (2023), 24696-24711.

[8] Yue Gao, Wei Qian, and Enfang Cui. 2023. RISC-V ISA extension toolchain supports: A survey. In Proceedings of the 2023 4th International Conference on Computing, Networks and Internet of Things. 924-929.

[9] Lukas Gerlach, Daniel Weber, Ruiyi Zhang, and Michael Schwarz. 2023. A security RISC: microarchitectural attacks on hardware RISC-V CPUs. In 2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2321-2338.

[10] Xuan Guo and Robert Mullins. 2019. Fast TLB simulation for RISC-V systems. arXiv preprint arXiv:1905.06825 (2019).

[11] Peter Yuen Ho Hin, Xiongfei Liao, Jin Cui, Andrea Mondelli, Thannir-malai Muthukaruppan Somu, and Naxin Zhang. 2021. Supporting RISC-V full system simulation in gem5. In Proc. Workshop Comput. Architect. Res. RISC-V.

[12] Chenhui Huang, Yu Sun, and Joe Rahmeh. [n. d.]. Unleashing the Power of Whisper for block-level verification in high performance RISC-V CPU. ([n. d.]).

[13] Nursultan Kabylkas, Tommy Thorn, Shreesha Srinath, Polychronis Xekalakis, and Jose Renau. 2021. Effective processor verification with logic fuzzer enhanced co-simulation. In MICRO-54: 54th Annual IEEE/ACM International Symposium on Microarchitecture. 667-678.

[14] Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, et al. 2020. Spectre attacks: Exploiting speculative execution. Commun. ACM 63, 7 (2020), 93-101.

[15] Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Haas, Stefan Mangard, Paul Kocher, Daniel Genkin, Yuval Yarom, and Mike Hamburg. 2018. Meltdown. arXiv preprint arXiv:1801.01207 (2018).

[16] Jason Lowe-Power. Sat 29 June 2024. Gem5 Documentation. [Online]. Available: https://www.gem5.org/documentation/.

[17] Jason Lowe-Power, Abdul Mutaal Ahmad, Ayaz Akram, Mohammad Alian, Rico Amslinger, Matteo Andreozzi, Adrià Armejach, Nils Asmussen, Brad Beckmann, Srikant Bharadwaj, et al. 2020. The gem5 simulator: Version 20.0+. arXiv preprint arXiv:2007.03152 (2020).

[18] Jason Lowe-Power, Venkatesh Akella, Matthew K Farrens, Samuel T King, and Christopher J Nitta. 2018. Position paper: A case for exposing extra-architectural state in the isa. In Proceedings of the 7th International Workshop on Hardware and Architectural Support for Security and Privacy. 1-6.

[19] Alec Roelke and Mircea R Stan. 2017. Risc5: Implementing the RISC-V ISA in gem5. In First Workshop on Computer Architecture Research with RISC-V (CARRV), Vol. 7.

[20] Ferenc Speiser, István Szalay, and Dénes Fodor. 2024. Embedded System Simulation Using Renode. Engineering Proceedings 79, 1 (2024), 52.

[21] Andrew Waterman, Krste Asanovic, and John Hauser. 2019. The RISC-V instruction set manual, volume II: Privileged architecture. RISC-V Foundation (2019), 1-4.

[22] Shan Zhou, Jinbo Wang, Jiao Jia, Chi Zhang, and Ruixue Wang. 2022. A formal verification method for the SOPC software. IEEE Transactions on Reliability 71, 2 (2022), 818-829.