The work centers on a new resource called the HARPY-V-GEM5 dataset, which the authors describe as the first publicly available collection for RISC-V that combines Hardware Performance Counter readings with committed-instruction mnemonic frequencies. RISC-V is a royalty-free, open Instruction Set Architecture whose modularity and transparency have made it attractive for research and embedded systems. That same openness, the researchers note, introduces non-uniformity across implementations and a broader attack surface at the hardware level, where conventional software-based protections often cannot see. Existing RISC-V datasets, they argue, mostly target functional correctness or benchmarking rather than security-oriented behavior, leaving a gap that their new corpus is designed to fill.

To build the dataset, the team executed 32 custom binaries—16 benign applications and 16 malicious exploits—inside the gem5 full-system simulator, version 24.1.0.3, in syscall-emulation mode. All programs were statically compiled with the RISC-V GCC toolchain, and the simulated processor was a single-core, single-threaded, out-of-order RISC-V core clocked at 3 GHz with 16 KiB L1 caches and a 256 KiB L2 cache. A custom gem5 patch allowed the researchers to extract committed instruction mnemonics alongside the standard performance counters, a combination that stock tooling does not provide. Sampling occurred at a fixed interval of every 10,000 committed instructions, a fine-grained resolution chosen to capture transient microarchitectural anomalies typical of side-channel activity, such as cache timing variations and speculative execution gadgets.

The malicious workloads spanned cache-based attacks, speculative execution exploits, timer-based techniques, and memory-access inference methods. The benign set drew from multimedia processing, data compression, text processing, numerical computation, and system performance evaluation, giving the models a broad picture of normal behavior. Because benign workloads typically run longer than exploits, the team applied a strict undersampling strategy: every trace was truncated from its beginning to the length of the shortest malicious workload, yielding exactly 12,890 samples per program and 412,480 samples in total. This enforced class balance eliminated the need for synthetic data augmentation techniques such as generative adversarial networks, ensuring that the models learned behavioral signatures rather than execution-length artifacts. One workload, GhostWrite, naturally produced only 2,340 samples and was extended through repeated iterations; the authors report that classifier performance remained stable whether trained on the original or extended trace.

For feature selection, the researchers used the SelectKBest method with univariate ANOVA F-tests, deliberately restricting themselves to counters commonly exposed by physical processors so that simulation results would translate to real hardware. An ablation study with the Random Forest classifier showed detection accuracy rising sharply from 67.17 percent with a single counter to 99.60 percent with four, plateauing beyond five features. The top-ranked counters included L1 and L2 cache accesses and misses along with branch prediction metrics. On the known-attack test set, Random Forest achieved 99.55 percent detection accuracy and an F1-score of 99.55 percent, with Decision Trees close behind at 99.54 percent. Both models also handled multi-class attack classification well with hardware counters, reaching 97.52 percent accuracy for Random Forest, suggesting that families as different as Spectre and Flush+Reload leave distinct microarchitectural footprints in cache and branch predictor stress.

Instruction-level features told a more lopsided story. Using the top eight committed instruction mnemonics, detection accuracy stayed above 99 percent, but classification of the specific attack family collapsed to roughly 60 percent. The explanation, the authors suggest, is that malicious code looks fundamentally different from benign code—likely due to a higher density of specific instructions and tight loops—while different types of malicious code look very similar to each other, since many exploits share common initialization routines such as flushing cache lines. An opcode distribution analysis reinforced this picture: benign programs were dominated by arithmetic and load instructions such as c_add and lw, whereas malicious programs showed a striking excess of compressed store double-word instructions, branch instructions like bne, and notably csrrs, an instruction used to access hardware performance counters and timing sources—operations central to side-channel attacks.

The study’s most sobering section is its zero-day evaluation. The authors ran a Leave-One-Program-Out cross-validation protocol in which an entire program—all 12,890 of its samples—was held out from training and used only for testing, simulating an encounter with a previously unseen binary. Aggregate results looked respectable: Random Forest reached 90.08 percent accuracy with hardware counter features and Decision Trees 85.67 percent. But the aggregate conceals extreme variability, with standard deviations between 25 and 36 percent across programs. Some held-out attacks, including spectrev2 at 1.34 percent accuracy and flush-fault-ret at 0.00 percent, were essentially undetectable when excluded from training, because the models had learned program-specific microarchitectural signatures rather than the underlying vulnerability patterns.

The failure modes of the two feature types, however, turned out to be largely complementary. Hardware counter models failed for attacks such as flush_fault, flush-fault-ret, interrupt-timing, and spectre-rsb, which nonetheless were detected with above 99 percent accuracy using instruction-based features. Conversely, the timing-driven timer-drift attack scored 0.00 percent with instruction features while being detected nearly perfectly with hardware counters, indicating that instruction frequencies alone cannot capture timing anomalies that counters expose directly. Only spectrev2 resisted both modalities. The authors also quantified overfitting: the gap between training accuracy and held-out accuracy was 21.6 percentage points for the hardware-counter Random Forest versus 9.7 points for the instruction-based Decision Tree, suggesting that counters, while more discriminative for known attacks, are more prone to learning program-specific artifacts.

Why choose simple trees over deep learning at all? The authors point to the computational constraints of embedded security monitors. A Decision Tree requires only O(d) comparisons per inference, where d is tree depth, while a neural network needs O(w) multiply-accumulate operations for its weight count; their analysis indicates Decision Tree inference is roughly three orders of magnitude faster than a moderately sized multilayer perceptron, with a memory footprint under 100 KB compared with several megabytes. They also observed that Support Vector Machines, which performed adequately on classification with an RBF kernel at 92.54 percent, failed badly at binary detection with 61.08 percent accuracy, hinting that the benign and malicious classes are not linearly separable. From these patterns the team distilled practical recommendations: an instruction-based Decision Tree detector for on-chip real-time monitoring, hardware-counter Random Forest classification as a second stage when attack attribution matters, and a hybrid two-stage pipeline combining both.

The researchers are explicit about the limits of their claims. Every experiment ran in gem5, which may not fully replicate the timing characteristics or idiosyncrasies of physical RISC-V silicon, and the classifiers may partly be learning patterns specific to the simulator rather than to real hardware. The malicious corpus consists of only 16 proof-of-concept exploit implementations, whereas real-world malware may behave in more varied and sophisticated ways. Validating the results on physical hardware, expanding coverage to attacks such as return-oriented programming and privilege escalation, and integrating the detectors into live runtime monitors are all flagged as future work. Even so, the study offers a reproducible baseline—and an honest accounting—for the idea that lightweight, interpretable models watching a processor’s own counters could become a practical line of defense for the next generation of open-ISA systems.

Subject of Research: Machine learning detection and classification of RISC-V hardware exploits using hardware performance counters and instruction telemetry

Article Title: Lightweight detection and classification of RISC-V hardware exploits using machine learning techniques

Article References: Pujol, J.-T., Otero, B., Verdú, J., & Canal, R. (2026). Lightweight detection and classification of RISC-V hardware exploits using machine learning techniques. Neural Computing and Applications, 38(20), 854. https://doi.org/10.1007/s00521-026-12467-4

Image Credits: AI Generated

DOI: 10.1007/s00521-026-12467-4

Keywords: RISC-V, hardware security, malware detection, machine learning, hardware performance counters, gem5 simulator, side-channel attacks, Random Forest, Decision Tree, zero-day attacks, HARPY-V-GEM5 dataset, microarchitectural telemetry