# Machine Learning-Based Detection of Microarchitectural Attacks on RISC-V via Gem5

Alessandro Palumbo

► To cite this version:

Alessandro Palumbo. Machine Learning-Based Detection of Microarchitectural Attacks on RISC-V via Gem5. TechDefense 2025 - IEEE International Workshop on Technologies for Defense and Security, Nov 2025, Rome, Italy. pp.1-6. hal-05288651

HAL Id: hal-05288651

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

Submitted on 29 Sep 2025

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 Attribution 4.0 International License
# Machine Learning-Based Detection of Microarchitectural Attacks on RISC-V via Gem5

Alessandro Palumbo

CentraleSupélec, Inria, CNRS, IRISA

alessandro.palumbo@inria.fr

***Abstract***—Microarchitectural Side-Channel Attacks (MSCAs) exploit low-level processor behavior to leak sensitive information during execution. An attacker can infer confidential data, including cryptographic keys or private messages, by observing timing differences in cache usage, memory access, and register activity. A notable example is *Spectre*, which leverages speculative execution and cache timing to gain unauthorized access to protected memory areas.

This study presents a methodology for detecting MSCAs in microprocessor-based systems through simulation using the gem5 platform, specifically focusing on RISC-V architectures. The System Emulation (SE) mode of gem5 is employed to simulate both benign and malicious scenarios, enabling the automated extraction of 1436 features from Hardware Performance Counters (HPCs) collected after each program execution. The constructed dataset consists of 15,000 samples, distributed between benign and attack instances, and spans eight benchmark applications.

Simulation-based approaches are shown to offer significant advantages in MSCA detection, particularly due to the broader access to microarchitectural events exposed via HPCs. Detection results involving two *Spectre*-based MSCAs demonstrate the effectiveness of Machine Learning (ML) techniques. A Random Forest (RF) classifier reaches an attack detection rate of 100%, with no undetected attacks or false alarms. The proposed framework provides a structured foundation for security evaluation under MSCA threats and supports the development of advanced ML-based detection strategies.

***Index Terms***—Microarchitectural Side-Channel Attacks, RISC-V, gem5, Machine Learning.

## I. INTRODUCTION

Security represents a fundamental requirement in modern digital systems, including Internet-of-Things (IoT) [1], Industry 4.0 [2], and automotive applications [3]. Classical security properties such as confidentiality, integrity, and non-repudiation are commonly enforced through cryptographic algorithms. Although these algorithms are mathematically secure, their practical implementations may introduce vulnerabilities. Hardware accelerators for cryptographic functions, for instance, have been shown to be susceptible to various forms of Side-Channel Analysis (SCA) [4], potentially compromising even systems equipped with dedicated security modules.

SCA techniques exploit unintentional information leakage by analyzing variations in timing, power consumption, thermal dissipation, or electromagnetic emissions during the execution of security-critical tasks. Such attacks typically require physical access and specialized measurement equipment [4]. In contrast, a newer class of attacks, the MSCAs, has emerged, targeting the shared resources of microprocessor-based systems [5]–[7]. Unlike traditional SCAs, MSCAs do not rely

on physical proximity and exploit timing discrepancies in shared microarchitectural elements such as caches and branch predictors. Due to the performance-driven nature of modern processors, strong correlations exist between execution timing, memory access behavior, and data flow, which can unintentionally expose sensitive information [5]–[7].

One of the most prominent examples is *Spectre* [8], which abuses speculative execution to circumvent memory isolation mechanisms without exploiting software vulnerabilities. By manipulating cache timing, an attacker may gain unauthorized access to protected data belonging to other processes or the operating system. These developments underscore the growing exposure of modern CPUs to subtle hardware-level threats, reinforcing the need for accurate detection mechanisms [9], [10]. The ability to detect MSCAs provides valuable insight into the nature of the attack, supporting the deployment of targeted defenses at both architectural and system levels. In this context, probabilistic models and ML techniques offer promising capabilities for MSCA detection [11]–[15]. By identifying fine-grained anomalies in processor behavior, ML methods enhance the detection of concealed or stealthy threats [16]–[19].

The gem5 simulator is an open-source framework widely adopted in the computer architecture research community [20], [21]. It enables detailed, cycle-accurate simulation of multiple ISAs, including RISC-V [22], [23]. Although gem5 is primarily used for evaluating performance and architectural designs, its fine-grained simulation capabilities also make it a valuable tool for security research. In particular, its cycle-level detail allows for a deep inspection of microarchitectural behavior, which is essential for studying MSCAs. Despite this potential, its use in security-focused investigations remains limited, warranting further exploration.

This work introduces a methodology for MSCA detection through ML techniques and simulation within the gem5 environment. The approach relies on HPCs to distinguish between benign and attack executions on RISC-V processors. The proposed method has been validated across various computational and cryptographic workloads. The main contributions of this study are summarized as follows:

*   **Microarchitectural Attack Simulations in gem5:** A practical methodology for modeling and simulating MSCAs in gem5, enabling the reproduction of realistic attack scenarios for security evaluation.
* **Feature Selection for MSCA Detection:** A comprehensive analysis of 1436 HPCs obtained from RISC-V simulation runs, identifying performance metrics most relevant for detecting *Spectre*-based attacks.

* **ML-based MSCA Detection:** Implementation of a classification method, achieving 100% detection accuracy with no false negatives or false positives.

Although real-world access to 1436 HPCs is generally constrained, this study aims to demonstrate a replicable methodology for selecting meaningful performance indicators and validating runtime detection techniques based on ML. The proposed framework provides a foundation for further investigations in MSCA security and supports the development of hardware-aware monitoring mechanisms for microprocessor-based systems.

The remainder of this manuscript is structured as follows: Section II provides an overview of related work on attack detection and simulation methodologies. Section III details the approach used to model and simulate MSCAs in gem5, along with the ML-based detection framework. Section IV outlines the experimental setup and presents the evaluation results. Section V discusses the proposed approach's practical implications and potential applications. Finally, Section VI summarizes the conclusions of the study.

## II. RELATED WORK

Various countermeasures against MSCAs have been proposed in recent years [33]. Since many MSCAs rely on measuring variations in execution time caused by data-dependent operations, so-called "constant-time" techniques aim to enforce uniform execution time using approaches such as bit-slicing [34], [35] or vector permutation [36]. Although these techniques are generally effective, their implementation is complex and often platform-specific, in addition to introducing substantial performance overhead.

Other mitigation strategies operate at the compiler level by modifying control flow. For instance, the approach presented in [37] employs a modified compiler to automatically identify and eliminate control flows that depend on sensitive data, thereby limiting exposure to attackers. Another strategy, described in [38], uses a compile-time generator to create semantically equivalent but structurally different execution paths, selecting one randomly at runtime. Despite their conceptual appeal, these methods typically suffer from limited applicability and non-negligible execution overhead.

In parallel, ML techniques have been explored for MSCA detection, including the use of neural networks [39] and decision trees [40], [41], often leveraging HPCs as features [15].

The gem5 simulator has become a standard tool in computer architecture research. Initially introduced by Binkert et al. [20], gem5 provides a flexible simulation environment for modeling CPUs, cache hierarchies, and interconnects at both full-system and microarchitectural levels. Over time, gem5 has expanded to support multiple ISAs, including x86, ARM, MIPS, Power, SPARC, and RISC-V [21]. Roelke and Stan [23] introduced

RISC5, the first RISC-V integration into gem5, enabling ISA-level simulation. Ta et al. [22] expanded this with multi-core support, synchronization primitives, and thread management validation. Ganjehloo et al. [42] combined gem5 with Chisel to achieve cycle-accurate microarchitectural modeling.

Beyond architectural analysis, gem5 has increasingly been applied to microarchitectural security research. Ayoub et al. [24] successfully ported the *Spectre* attack to an x86-based gem5 environment. Forcioli et al. [25] designed a virtual platform based on gem5 to evaluate transient execution attacks (*Spectre*, *Meltdown*), cache-based side channels (*Flush+Reload*, *Prime+Probe*), and fault injection methods such as *Rowhammer*, with an extension in [26] focusing on Trusted Execution Environments (TEEs) across ARM, RISC-V, and x86 ISAs. Similarly, Awais et al. [27] examined instruction-level side-channel and transient execution attacks using gem5 as an analysis platform.

Gem5 has also served as a foundation for simulating defense mechanisms. Choudhari et al. [30] introduced *SpecDefender*, a real-time detection technique using HPCs to identify Spectre-style transient execution attacks. Peters et al. [31] studied cache replacement policies and proposed randomized strategies to defend against *Prime+Probe* and *Flush+Reload*.

Recent studies have also examined Hardware Trojans (HTs) in the context of gem5. De et al. [28] proposed *HarTBleed*, an attack leveraging HTs embedded in the TLB to remap virtual addresses and leak sensitive data. Khan et al. [29] demonstrated *Cache-Out*, in which a HT placed in the L1 cache manipulates SRAM to exfiltrate private data. Building upon the methodology introduced in [32]–which employed gem5’s SE mode and HPCs for the simulation and Machine Learning-based detection of HTs in RISC-V processors–this study adapts and extends the same methodological framework to the domain of *Spectre*-based attacks. Specifically, the proposed approach adopts a similar simulation and data collection strategy, but targets the detection of speculative execution vulnerabilities through supervised ML techniques.

A relevant study targeting the x86 ISA on gem5 is presented in [15], where HPC-derived features were exploited to detect *Spectre* and *Meltdown* attacks using ML classifiers. Building upon this line of work, the methodology described in this manuscript simulates *Spectre*-based MSCAs on RISC-V architectures and applies an ML-based detection mechanism using HPCs as classification features.

Table I summarizes gem5-based studies in the field of microarchitectural security. The columns *M* and *D* indicate whether mitigation strategies or detection techniques were included, respectively. As a case study for the proposed detection methodology, the focus is placed on *Spectre*-based attacks ported to the RISC-V architecture on gem5: a scenario that, to the best of available knowledge, has not been addressed in previous works.
<table><caption>TABLE I
RELATED WORKS BASED ON SECURITY EVALUATIONS VIA GEM5</caption><thead><tr><th rowspan="2">Ref.</th><th colspan="10">Considered vulnerabilities</th><th colspan="3">Targeted ISA</th><th rowspan="2">M</th><th rowspan="2">D</th></tr><tr><th>Spectre</th><th>Meltdown</th><th>Flush+Reload</th><th>Prime+Probe</th><th>Rowhammer</th><th>ARM TrustZone</th><th>HTs</th><th>x86</th><th>ARM</th><th>RISC-V</th></tr></thead><tbody><tr><td>P. Ayoub et al. [24]</td><td>✓</td><td></td><td></td><td></td><td></td><td></td><td></td><td>✓</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Q. Forciol et al. [25]</td><td>✓</td><td>✓</td><td></td><td>✓</td><td>✓</td><td></td><td></td><td></td><td>✓</td><td>✓</td><td></td><td></td><td></td></tr><tr><td>Q. Forciol et al. [26]</td><td></td><td>✓</td><td>✓</td><td>✓</td><td></td><td>✓</td><td></td><td></td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr><tr><td>M. Awais et al. [27]</td><td>✓</td><td></td><td>✓</td><td>✓</td><td></td><td></td><td></td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td><td>✓</td></tr><tr><td>A. De et al. [28]</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>✓</td><td>✓</td><td></td><td></td><td>✓</td><td></td></tr><tr><td>M. N. I. Khanet al. [29]</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>✓</td><td>✓</td><td></td><td></td><td>✓</td><td></td></tr><tr><td>A. Choudhari et al. [30]</td><td>✓</td><td></td><td>✓</td><td></td><td></td><td></td><td></td><td></td><td>✓</td><td></td><td></td><td>✓</td><td>✓</td></tr><tr><td>M. Peters et al. [31]</td><td></td><td></td><td>✓</td><td>✓</td><td></td><td></td><td></td><td></td><td></td><td></td><td>✓</td><td>✓</td><td>✓</td></tr><tr><td>Palumbo et al. [32]</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>✓</td><td></td><td></td><td>✓</td><td></td><td>✓</td></tr><tr><td>M. Iamundo [15]</td><td>✓</td><td>✓</td><td></td><td></td><td></td><td></td><td></td><td>✓</td><td></td><td></td><td></td><td>✓</td><td>✓</td></tr><tr><td>This work</td><td>✓</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>✓</td><td>✓</td><td></td><td></td><td>✓</td></tr></tbody></table>

### III. METHODOLOGY

#### A. MSCAs Simulation Framework in gem5

In gem5, the simulated processor with its components are defined through `.cc` source files, where specific architectural modules can be selected for simulation. Once the simulator is built, configuration scripts (typically written in Python) are then used to set up and customize benchmark executions.

The gem5 simulator in SE mode simulated both benign and malicious scenarios. SE mode allows user-space applications to be executed without requiring a full operating system. The simulation setup targeted the RISC-V ISA, specifically using the `RiscvO3CPU()` core, an out-of-order processor model provided within gem5. In addition to the core itself, the simulation included L1 and L2 caches, as well as the default branch predictor of this CPU model, namely the *Branch Target Buffer* (BTB).

A set of benchmark applications was used to generate realistic execution patterns, and HPCs were extracted per run to capture relevant microarchitectural behaviors. To enable detailed behavioral analysis, these applications were executed under two conditions: standard execution and execution under attack. Two `Spectre`-based attacks were integrated directly into the code to simulate realistic threat scenarios. After each simulation run, gem5 generated a statistics file containing the HPC data, which served as the basis for feature extraction and subsequent ML analysis.

#### B. Spectre Attack Variants Overview

`Spectre` is a class of MSCAs that exploit speculative execution (a performance optimization used in modern CPUs) to leak sensitive information across security boundaries [8]. By misleading the processor's branch predictor, `Spectre` allows the transient execution of instructions that would not occur in a strictly sequential program flow. Although these instructions are eventually rolled back, their microarchitectural side effects, such as cache modifications, remain and can be observed via side channels. Two `Spectre` variants (i.e., v1 and v2) were considered in this study, taken from [43].

#### C. Data Collection and Processing

HPC data was systematically collected across multiple simulation runs to construct a robust dataset for ML-based detection. Each workload was executed repeatedly under both

benign and malicious conditions in SE mode to emulate real-world execution variability.

For each execution of the considered benchmarks (reported in Table II), gem5 produced a statistics file containing over 1436 HPCs. The final dataset comprises 15,000 samples, each represented by a vector of 1436 metrics. These were obtained by executing 8 benchmarks under three scenarios: (1) benign execution; (2) execution with a nested `Spectrev1` payload; and (3) execution affected by `Spectrev2`. Each benchmark was repeated 625 times per scenario, yielding 5,000 samples for each scenario and 15,000 samples in total. Repeated executions of the same programs introduced variability, resulting in diverse HPC profiles across workloads and input data.

<table><caption>TABLE II
THE CONSIDERED BENCHMARKS</caption><thead><tr><td>Benchmark</td><td>Description</td></tr></thead><tbody><tr><td>AES</td><td>A famous encryption algorithm</td></tr><tr><td>BlowFish</td><td>A fast symmetric-key block cipher</td></tr><tr><td>CRC</td><td>The Cyclic Redundancy Check, for error detection</td></tr><tr><td>Dijkstra</td><td>An algorithm for finding the shortest path in a graph</td></tr><tr><td>FFT</td><td>The Fast Fourier Transform, for signal processing</td></tr><tr><td>Idea</td><td>A block cipher used for secure data encryption</td></tr><tr><td>QSORT</td><td>A famous sorting method</td></tr><tr><td>RSA</td><td>An famous asymmetric encryption algorithm</td></tr></tbody></table>

#### D. ML Pipeline for MSCA Detection

Figure 1 illustrates the workflow of the proposed methodology. The process begins with the gem5 simulator, which models the behavior of the target RISC-V core. Once the processor type is configured, a series of benchmark programs is executed to generate representative execution traces. These traces allow for analyzing microarchitectural behavior under controlled conditions. After each run, gem5 produces statistics files containing 1436 HPCs (i.e., the ML dataset input samples represented as a vector of 1436 HPC values).

Once the datasets for both benign and attack scenarios are collected, as described in Section III-C, they are processed through a ML pipeline for classification. The dataset was randomly split into training (80%) and test (20%) subsets to ensure unbiased evaluation of the classifier.

A RF classifier is used as a representative case study to evaluate whether MSCAs can be effectively detected using HPC-based features. It was trained using the `scikit-learn` library to evaluate the relevance of HPC-derived features in
distinguishing between benign and *Spectre*-compromised
executions. The trained model provided an internal ranking
of feature importance, highlighting the HPCs that contributed
most significantly to the classification task. This ranking forms
the basis for analyzing which microarchitectural events are
most affected by speculative execution attacks.

While the current implementation adopts an RF model, the
proposed framework is designed to be model-agnostic and
can accommodate other supervised learning algorithms. The
primary objective of this manuscript is not to compare ML
models, but to present a methodology for porting MSCAs to
gem5 running RISC-V CPUs, detail the gem5-based detection
approach, and demonstrate the effectiveness of HPC-based
signatures in identifying MSCA activity.

IV. EVALUATION

A. *Experimental Setup*

Several dependencies must be installed to enable RISC-V simulation with gem5, including development tools and essential libraries. The environment setup procedure, including gem5 cloning and RISC-V build configuration, is reported in [44]. The build process relies on the `.cc` files within the source directory, which define the behavior and structure of the microarchitectural components such as cores, caches, and memory controllers. This configuration enables the simulation of a custom processor design. The high-level architecture of the simulated RISC-V microprocessor is shown in Figure 2.

After successfully building the microprocessor, the `gem5.opt` binary is generated. At this point, the environment is ready for program execution and performance data collection. The Python script `simple-riscv.py`, located in `configs/learning_gem5/part1` of the downloaded default gem5 github repository [45], is used as the configuration file for simulation. This script allows customization of processor features, including core type (in-order/out-of-order), cache configuration, memory range, and clock frequency.

The benchmark object files listed in Table II were pre-
compiled using the RISC-V toolchain. Two Spectre-based
attack routines were embedded within the benign programs to
simulate compromised scenarios, resulting in modified binaries
that preserve the original structure while introducing spec-
ulative execution vulnerabilities. These binaries were linked
within the configuration Python script to ensure repeatable
and controlled execution. Upon completion of each run, gem5
produces a stats.txt file (located in m5out/) contain-
ing detailed performance metrics. Multiple simulations were
performed as described in earlier sections, and the resulting
HPC data from each execution (the samples in Figure 1) were
collected and aggregated into a structured dataset for ML-
based detection.

B. Results

The proposed methodology was evaluated using a RF clas-
sifier, which achieved a precision of 100% in detecting the
considered MSCA scenarios, with no missed or incorrectly

<figure><img src="image_2.png" /><figcaption>Fig. 1. Workflow of the proposed methodology</figcaption></figure>

classified attacks. Following the execution of both benign
and malicious workloads, the most influential HPCs for the
attack detections were identified. Table III reports the top 25
HPCs ranked by importance, as determined by the feature
importance score of the RF model implemented using the
`scikit-learn` library. A brief description of each HPC's
functional role is provided in Table III.
<figure><img src="image_3.png" /><figcaption>Fig. 2. The overview of the simulated RISC-V microprocessor</figcaption></figure>

Although the model achieves high classification performance, in practical scenarios, accessing a large number of HPCs may be infeasible due to architectural or performance constraints. Nevertheless, the primary contribution of this study is to present a simulation-based methodology for systematically mapping MSCAs within the gem5 framework and validating the effectiveness of ML-based detection techniques. The current implementation serves as a proof of concept, demonstrating the viability of such an approach.

<table><caption>TABLE III
TOP 25 FEATURES RANKED BY IMPORTANCE WITH DESCRIPTIONS</caption><thead><tr><td>Rank</td><td>Feature</td><td>Description</td></tr></thead><tbody><tr><td>1</td><td>system.memCtrl.dram.perBankWrBursts_1</td><td>DRAM write bursts in bank 1</td></tr><tr><td>2</td><td>system.memCtrl.dram.perBankWrBursts_15</td><td>DRAM write bursts in bank 15</td></tr><tr><td>3</td><td>system.memCtrl.dram.perBankRdBursts_11</td><td>DRAM read bursts in bank 11</td></tr><tr><td>4</td><td>system.memCtrl.dramUtil</td><td>DRAM bus utilization</td></tr><tr><td>5</td><td>system.memCtrl.avgGap</td><td>Average gap between memory requests</td></tr><tr><td>6</td><td>system.cpu.commitStats0.ipc</td><td>Instructions per cycle (IPC)</td></tr><tr><td>7</td><td>system.membus.regLayer0.utilization</td><td>Memory bus request layer 0 utilization</td></tr><tr><td>8</td><td>system.memCtrl.dram.readRowHitRate</td><td>DRAM row read hit rate</td></tr><tr><td>9</td><td>system.cpu.fetchStats0.fetchRate</td><td>Instruction fetch rate</td></tr><tr><td>10</td><td>system.memCtrl.dram.bwTotal_cpu.inst</td><td>Total bandwidth for CPU instructions</td></tr><tr><td>11</td><td>system.memCtrl.dram.perBankWrBursts_5</td><td>DRAM write bursts in bank 5</td></tr><tr><td>12</td><td>system.memCtrl.readPktSize_6</td><td>Read packet size (index 6)</td></tr><tr><td>13</td><td>system.memCtrl.dram.writeRowHitRate</td><td>DRAM row write hit rate</td></tr><tr><td>14</td><td>system.memCtrl.wrQLenPdf_30</td><td>Write queue length PDF (bin 30)</td></tr><tr><td>15</td><td>system.cpu.cpi</td><td>Cycles per instruction (CPI)</td></tr><tr><td>16</td><td>system.memCtrl.dram.writeBursts</td><td>Number of DRAM write bursts</td></tr><tr><td>17</td><td>system.membus.respLayer0.utilization</td><td>Memory bus response layer 0 utilization</td></tr><tr><td>18</td><td>system.memCtrl.dram-rank1.pwrStateTime_REF</td><td>Time in REF power state (rank 1)</td></tr><tr><td>19</td><td>system.cpu.numCycles</td><td>Total CPU cycles</td></tr><tr><td>20</td><td>system.cpu thread_0.numOps</td><td>Number of operations by thread 0</td></tr><tr><td>21</td><td>system.memCtrl.dram.avgMemAccLat</td><td>Average memory access latency</td></tr><tr><td>22</td><td>system.memCtrl.wrQLenPdf_29</td><td>Write queue length PDF (bin 29)</td></tr><tr><td>23</td><td>simSeconds</td><td>Total simulated seconds</td></tr><tr><td>24</td><td>system.memCtrl.dram.perBankWrBursts_4</td><td>DRAM write bursts in bank 4</td></tr><tr><td>25</td><td>system.memCtrl.wrQLenPdf_22</td><td>Write queue length PDF (bin 22)</td></tr></tbody></table>

The first 25 most relevant HPCs identified by the RF classifier primarily reflect memory-level activity and execution flow metrics. In particular, per-bank DRAM read/write bursts and bus utilization are likely influenced by unauthorized speculative memory accesses triggered by the *Spectre* attacks. Similarly, variations in IPC, CPI and fetch rate indicate altered instruction flow due to speculative execution. Features such as average memory request gap, queue length distributions, and power state timing further capture anomalies introduced by the transient behavior of attack code.

## V. HARDWARE SECURITY IMPACT

The growing complexity of microprocessor architectures increases the likelihood of emerging attack surfaces, making detecting MSCAs a pressing challenge in hardware security. The methodology proposed in this work contributes to this objective by enabling the detection of MSCAs through systematic simulation in gem5 and subsequent ML-based analysis. A

key advantage of the framework is the ability to simulate and analyze MSCAs without access to physical hardware. This feature allows researchers and engineers to investigate complex attack patterns in a controlled and reproducible environment, fostering a deeper understanding of microarchitectural vulnerabilities and their potential impact. The proposed framework supports several practical applications in both academic and industrial domains:

* **Security Verification in Microprocessor Design:** Semiconductor vendors can apply the methodology during pre-silicon verification to assess the resilience of new microarchitectural designs against MSCA threats.

* **Threat Modeling for Secure Architectures:** The framework facilitates the modeling of realistic attack scenarios and the evaluation of defense mechanisms.

* **Hardware-Assisted Intrusion Detection:** HPC-based anomaly detection systems derived from this methodology can be integrated into critical systems (e.g., defense, finance, telecommunications) to support real-time threat monitoring.

* **Security Testing for Microprocessors:** The simulation environment can assist in security audits by injecting hardware-level attack patterns and analyzing their effects on system behavior.

## VI. CONCLUSION

This study introduced a simulation-based methodology for detecting MSCAs in RISC-V processors using the gem5 simulator and a ML-based classification approach. By embedding two *Spectre*-based attack variants into benchmark programs and executing them in a controlled simulation environment, a dataset of 15,000 runs was constructed. 1436 Hardware HPCs were extracted from each execution and used to train and evaluate a RF classifier.

The experimental results demonstrated that the proposed framework is capable of accurately distinguishing between benign and compromised executions, achieving 100% precision in detecting the modeled attacks, with no false negatives or positives. A ranking of the most relevant HPCs was also produced, highlighting the microarchitectural events most impacted by speculative execution vulnerabilities.

## REFERENCES

[1] L. Wang and S. Köse, "When hardware security moves to the edge and fog," in *2018 IEEE 23rd International Conference on Digital Signal Processing (DSP)*, 2018, pp. 1–5.

[2] S. R. Chhetri, S. Faezi, N. Rashid, and M. A. Al Faruque, "Manufacturing supply chain and product lifecycle security in the era of industry 4.0," *Journal of Hardware and Systems Security*, vol. 2, no. 1, pp. 51–68, 2018.

[3] D. K. Oka, "Securing the automotive critical infrastructure," in *Cyber-Physical Security*. Springer, 2017, pp. 267–281.

[4] R. Spreitzer, V. Moonsamy, T. Korak, and S. Mangard, "Systematic classification of side-channel attacks: A case study for mobile devices," *IEEE Communications Surveys Tutorials*, vol. 20, no. 1, pp. 465–488, 2018.

[5] A. P. Fournaris, L. Pocero Fraile, and O. Koufopavlou, "Exploiting hardware vulnerabilities to attack embedded system devices: a survey of potent microarchitectural attacks," *Electronics*, vol. 6, no. 3, p. 52, 2017.
[6] J. Yuan, J. Zhang, P. Qiu, X. Wei, and D. Liu, "A survey of side-channel attacks and mitigation for processor interconnects," Applied Sciences, vol. 14, no. 15, 2024. [Online]. Available: https://www.mdpi.com/2076-3417/14/15/6699

[7] X. Lou, T. Zhang, J. Jiang, and Y. Zhang, "A survey of microarchitectural side-channel vulnerabilities, attacks, and defenses in cryptography," ACM Computing Surveys (CSUR), vol. 54, no. 6, pp. 1-37, 2021.

[8] P. Kocher, J. Horn, A. Fogh, D. Genkin, D. Gruss, W. Haas, M. Hamburg, M. Lipp, S. Mangard, T. Prescher et al., "Spectre attacks: Exploiting speculative execution," Communications of the ACM, vol. 63, no. 7, pp. 93-101, 2020.

[9] P. R. Nikiema et al., "Towards dependable risc-v cores for edge computing devices," in 2023 IEEE 29th International Symposium on On-Line Testing and Robust System Design (IOLTS), 2023, pp. 1-7.

[10] L. Cassano et al., "Is risc-v ready for space? a security perspective," in 2022 IEEE International Symposium on Defect and Fault Tolerance in VLSI and Nanotechnology Systems (DFT), 2022, pp. 1-6.

[11] A. Palumbo et al., "A lightweight security checking module to protect microprocessors against hardware trojan horses," in 2021 IEEE International Symposium on Defect and Fault Tolerance in VLSI and Nanotechnology Systems (DFT), 2021, pp. 1-6.

[12] ——, "Built-in software obfuscation for protecting microprocessors against hardware trojan horses," in 2023 IEEE International Symposium on Defect and Fault Tolerance in VLSI and Nanotechnology Systems (DFT), 2023, pp. 1-6.

[13] ——, "Improving the detection of hardware trojan horses in microprocessors via hamming codes," in 2023 IEEE International Symposium on Defect and Fault Tolerance in VLSI and Nanotechnology Systems (DFT), 2023, pp. 1-6.

[14] K. Arıkan et al., "Processor security: Detecting microarchitectural attacks via count-min sketches," IEEE Transactions on Very Large Scale Integration (VLSI) Systems, vol. 30, no. 7, pp. 938-951, 2022.

[15] M. Iamundo, "A machine learning-based security architecture to detect microarchitectural side-channel attacks in microprocessors," Master's Thesis, Politecnico di Milano, 2021.

[16] K. G. o. Liakos, "Machine learning for hardware trojan detection: A review," in 2019 Panhellenic Conference on Electronics & Telecommunications (PACET), 2019, pp. 1-6.

[17] K. I. Gubbi et al., "Hardware trojan detection using machine learning: A tutorial," ACM Trans. Embed. Comput. Syst., vol. 22, no. 3, Apr. 2023. [Online]. Available: https://doi.org/10.1145/3579823

[18] A. Palumbo et al., "Is your fpga bitstream hardware trojan-free? machine learning can provide an answer," Journal of Systems Architecture, vol. 128, p. 102543, 2022. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S1383762122001023

[19] S. Ribes et al., "Machine learning-based classification of hardware trojans in fpgas implementing risc-v cores." in ICISSP, 2024, pp. 717-724.

[20] N. Binkert et al., "The gem5 simulator," SIGARCH Comput. Archit. News, vol. 39, no. 2, pp. 1-7, Aug. 2011.

[21] Lowe-Power et al., "The gem5 Simulator: Version 20.0+," arXiv:2007.03152 [cs], Sep. 2020.

[22] T. Ta et al., "Simulating Multi-Core RISC-V Systems in gem5," in Workshop on Computer Architecture Research with RISC-V, 2018.

[23] A. Roelke and M. R. Stan, "RISC5: Implementing the RISC-V ISA in gem5," in First Workshop on Computer Architecture Research with RISC-V (CARRV), vol. 7, 2017.

[24] P. Ayoub and C. Maurice, "Reproducing Spectre Attack with gem5: How To Do It Right?" in Proceedings of the 14th European Workshop on Systems Security, ser. EuroSec '21. New York, NY, USA: Association for Computing Machinery, Apr. 2021, pp. 15-20.

[25] Q. Forcioli et al., "Virtual Platform to Analyze the Security of a System on Chip at Microarchitectural Level," in 2021 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), Sep. 2021, pp. 96-102.

[26] Q. Forcioli et al., "A gem5 based Platform for Micro-Architectural Security Analysis," in Proceedings of the 12th International Workshop on Hardware and Architectural Support for Security and Privacy, ser. HASP '23. New York, NY, USA: Association for Computing Machinery, Oct. 2023, pp. 91-99.

[27] M. Awais et al., "Decoding Attack Behaviors by Analyzing Patterns in Instruction-Based Attacks using gem5," in 2024 International Workshop on Rapid System Prototyping (RSP), Oct. 2024, pp. 1-6.

[28] A. De et al., "HarTBleed: Using Hardware Trojans for Data Leakage Exploits," IEEE Transactions on Very Large Scale Integration (VLSI) Systems, vol. 28, no. 4, pp. 968-979, Apr. 2020.

[29] M. N. I. Khan et al., "Cache-Out: Leaking Cache Memory Using Hardware Trojan," IEEE Transactions on Very Large Scale Integration (VLSI) Systems, vol. 28, no. 6, pp. 1461-1470, Jun. 2020.

[30] A. Choudhari et al., "SpecDefender: Transient Execution Attack Defender using Performance Counters," in Proceedings of the 2022 Workshop on Attacks and Solutions in Hardware Security, ser. ASHES'22. New York, NY, USA: Association for Computing Machinery, Nov. 2022, pp. 15-24.

[31] M. Peters et al., "On The Effect of Replacement Policies on The Security of Randomized Cache Architectures," in Proceedings of the 19th ACM Asia Conference on Computer and Communications Security, ser. ASIA CCS '24. New York, NY, USA: Association for Computing Machinery, Jul. 2024, pp. 483-497.

[32] A. Palumbo and R. Salvador, "Leveraging gem5 for hardware trojan research: Simulation for machine-learning-based detection," in Proceedings of the 3rd International Workshop on Malware in the Internet of Things (Mal-IoT '25). Cagliari, Italy: ACM, May 2025.

[33] Y. Lyu and P. Mishra, "A survey of side-channel attacks on caches and countermeasures," Journal of Hardware and Systems Security, vol. 2, no. 1, pp. 33-50, 2018.

[34] M. Matsui and J. Nakajima, "On the power of bitslice implementation on intel core2 processor," in International Workshop on Cryptographic Hardware and Embedded Systems. Springer, 2007, pp. 121-134.

[35] E. Käsper and P. Schwabe, "Faster and timing-attack resistant aes-gcm," in International Workshop on Cryptographic Hardware and Embedded Systems. Springer, 2009, pp. 1-17.

[36] M. Hamburg, "Accelerating aes with vector permute instructions," in International Workshop on Cryptographic Hardware and Embedded Systems. Springer, 2009, pp. 18-32.

[37] B. Coppens, I. Verbauwhede, K. De Bosschere, and B. De Sutter, "Practical mitigations for timing-based side-channel attacks on modern x86 processors," in 2009 30th IEEE Symposium on Security and Privacy. IEEE, 2009, pp. 45-60.

[38] S. Crane, A. Homescu, S. Brunthaler, P. Larsen, and M. Franz, "Thwarting cache side-channel attacks through dynamic software diversity." in NDSS, 2015, pp. 8-11.

[39] M. Chiappetta, E. Savas, and C. Yilmaz, "Real time detection of cache-based side-channel attacks using hardware performance counters," Applied Soft Computing, vol. 49, pp. 1162-1174, 2016.

[40] H. Wang, H. Sayadi, S. Rafatirad, A. Sasan, and H. Homayoun, "Scarf: Detecting side-channel attacks at real-time using low-level hardware features," in 2020 IEEE 26th International Symposium on On-Line Testing and Robust System Design (IOLTS), 2020, pp. 1-6.

[41] H. Wang, H. Sayadi, G. Kolhe, A. Sasan, S. Rafatirad, and H. Homayoun, "Phased-guard: Multi-phase machine learning framework for detection and identification of zero-day microarchitectural side-channel attacks," in 2020 IEEE 38th International Conference on Computer Design (ICCD), 2020, pp. 648-655.

[42] N. Ganjehloo et al., "Integrating Cycle-Accurate Chisel Models with gem5's System Simulation," in Chisel Community Conference, 2018.

[43] RISC-V BOOM Attacks Repository, "Spectre Attacks on RISC-V BOOM," 2024, accessed: March 20, 2025. [Online]. Available: https://github.com/riscv-boom/boom-attacks

[44] gem5 Project. (2025) Learning gem5: Introduction. [Online]. Available: https://www.gem5.org/documentation/learning_gem5/introduction/

[45] ——, "gem5 simulator - stable branch," https://github.com/gem5/gem5/tree/stable, 2025, accessed: 2025-05-15.