Machine learning spots RISC-V hardware attacks from processor performance
Open-source hardware has a security problem, but a team of researchers has now tested how much machine learning can help solve it. Their results are promising, but there is an important limit: simple machine learning models based on decision trees can detect known attacks with more than 99 percent accuracy. However, their ability to detect completely new attacks varies greatly depending on the type of attack.
The research focuses on a new resource called the HARPY-V-GEM5 dataset. The researchers describe it as the first publicly available RISC-V dataset that combines readings from Hardware Performance Counters with counts of the instruction names a processor has completed. RISC-V is an open, royalty-free design for processor instructions. Its flexible and transparent design makes it useful for research and devices with limited resources. However, the researchers explain that different RISC-V processors can work in different ways, creating more opportunities for hardware attacks. Traditional software security tools often cannot detect these attacks. Existing RISC-V datasets mainly focus on checking whether hardware works correctly or measuring its performance, rather than studying security. The new dataset aims to fill this gap.
To create the dataset, the team ran 32 custom programs inside the gem5 full-system simulator, version 24.1.0.3, using system-call emulation mode. The programs included 16 harmless applications and 16 malicious exploits. All programs were compiled into static binaries using the RISC-V GCC tools. The simulated processor had one core, one thread, an out-of-order design, a clock speed of 3 GHz, 16 KiB of L1 cache, and 256 KiB of L2 cache. The team made a custom change to gem5 so it could record completed instruction names alongside the usual performance counter readings. The standard tools do not provide this combination. The researchers collected data after every 10,000 completed instructions. This fine-grained sampling was chosen to capture short-lived changes inside the processor that can reveal side-channel attacks, including changes in cache timing and the effects of speculative execution, where a processor works ahead before knowing whether a result will be needed.
The malicious programs covered several types of attacks, including attacks based on cache behavior, speculative execution, timers, and methods for guessing how memory is accessed. The harmless programs covered multimedia processing, data compression, text processing, mathematical calculations, and system performance testing. This gave the models a wide range of examples of normal computer activity. Because harmless programs usually run longer than exploits, the researchers used a strict method to balance the data. They cut every program's trace, or recorded activity, from the beginning to match the length of the shortest malicious program. This produced exactly 12,890 samples per program and 412,480 samples in total. Balancing the number of samples in this way meant the researchers did not need to create artificial training data using methods such as generative adversarial networks. It also helped ensure that the models learned patterns of behavior rather than simply learning how long programs ran. One program, GhostWrite, naturally produced only 2,340 samples, so the team extended its trace by running it repeatedly. The researchers report that classifier performance remained stable whether they trained the models on the original trace or the extended one.
To choose which measurements the models should use, the researchers applied a method called SelectKBest with one-way ANOVA F-tests. They deliberately chose counters that are commonly available on physical processors so that the results from the simulator could be more useful on real hardware. In a test using the Random Forest model, the team found that detection accuracy increased sharply from 67.17 percent with one counter to 99.60 percent with four counters. Adding more than five features brought little further improvement. The most useful measurements included L1 and L2 cache accesses and misses, as well as branch prediction measurements. When tested on known attacks, Random Forest achieved 99.55 percent accuracy and an F1-score of 99.55 percent. The Decision Tree model performed almost as well, with 99.54 percent accuracy. Both models also did well at identifying the specific type of attack using hardware counters. Random Forest reached 97.52 percent accuracy for this task. These results suggest that different attacks, such as Spectre and Flush+Reload, leave different traces inside the processor by putting different kinds of pressure on caches and branch predictors.
Features based on instruction names produced a different result. When the models used the eight most common completed instruction names, they detected malicious programs with more than 99 percent accuracy. However, they could identify the specific type of attack correctly only about 60 percent of the time. The researchers suggest that malicious programs look quite different from harmless ones, perhaps because they use certain instructions more often and contain tight loops. Different malicious programs, however, may look much more alike because many exploits share common setup steps, such as clearing cache lines. An analysis of instruction counts supported this explanation. Harmless programs mainly used arithmetic instructions and load instructions, such as c_add and lw. Malicious programs used far more compressed store double-word instructions, branch instructions such as bne, and especially csrrs. This last instruction can access hardware performance counters and timing sources, which are important for side-channel attacks.
The most concerning part of the study tested whether the models could detect zero-day attacks, meaning attacks they had not seen during training. The researchers used a method called Leave-One-Program-Out cross-validation. For each test, they kept one entire program and all 12,890 of its samples out of training, then used those samples only for testing. This simulated what might happen when a detector encounters a previously unseen program. The overall results looked promising: Random Forest reached 90.08 percent accuracy using hardware counter features, while Decision Trees reached 85.67 percent. However, these averages hid large differences between programs. The standard deviations ranged from 25 to 36 percentage points. Some attacks were almost impossible for the models to detect when they had not appeared in training. For example, accuracy was just 1.34 percent for spectrev2 and 0.00 percent for flush-fault-ret. The researchers explain that the models had learned patterns specific to individual programs rather than the deeper patterns linked to the security weaknesses being exploited.
However, the two types of features often failed on different attacks, meaning they could work well together. Models using hardware counters struggled with attacks such as flush_fault, flush-fault-ret, interrupt-timing, and spectre-rsb. Models using instruction-based features detected these attacks with more than 99 percent accuracy. The opposite happened with timer-drift, an attack that relies on timing. Instruction-based features detected it with 0.00 percent accuracy, while hardware counters detected it almost perfectly. This suggests that instruction counts alone cannot capture timing changes that hardware counters can reveal directly. Only spectrev2 resisted both types of features. The researchers also measured overfitting, which happens when a model learns details of its training examples that do not work well on new examples. The difference between training accuracy and accuracy on held-out programs was 21.6 percentage points for the hardware-counter Random Forest model, compared with 9.7 percentage points for the instruction-based Decision Tree model. This suggests that hardware counters are better at distinguishing known attacks but are also more likely to learn patterns specific to individual programs.
Why use simple tree-based models instead of deep learning? The researchers point to the limited computing power available in embedded security monitors. A Decision Tree needs only O(d) comparisons to make a prediction, where d is the depth of the tree. A neural network needs O(w) multiply-and-accumulate operations, where w is the number of weights in the network. Their analysis suggests that a Decision Tree can make predictions about 1,000 times faster than a moderately sized multilayer perceptron, a type of neural network. It also needs less than 100 KB of memory, compared with several megabytes for the neural network. The researchers also tested Support Vector Machines. These achieved 92.54 percent accuracy when classifying categories using a radial basis function (RBF) kernel, but performed poorly at the simpler task of separating harmless programs from malicious ones, reaching just 61.08 percent accuracy. This suggests that the two groups cannot be easily separated by a straight boundary in the feature space. Based on these results, the team recommends three approaches: use an instruction-based Decision Tree to monitor the processor in real time, use a hardware-counter Random Forest model as a second step when identifying the type of attack is important, or combine both methods in a two-stage system.
The researchers clearly explain the limits of their findings. All experiments used gem5, a simulator that may not fully reproduce the timing behavior or other details of real RISC-V processors. The models might therefore be learning patterns that are specific to the simulator rather than to actual hardware. The malicious dataset also contains only 16 proof-of-concept exploit implementations, while real-world malware may behave in more varied and advanced ways. The researchers identify several important next steps: testing the methods on physical hardware, adding more types of attacks such as return-oriented programming and privilege escalation, and integrating the detectors into systems that monitor processors while they run. Even with these limitations, the study provides a repeatable starting point and a clear account of what works and what does not. It suggests that lightweight, understandable machine learning models that monitor a processor's own performance counters could become a practical way to protect future systems built on open instruction set architectures.
Subject of Research: Using machine learning to detect and classify RISC-V hardware exploits through hardware performance counters and instruction data
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