# Decoding Attack Behaviors by Analyzing Patterns in Instruction-Based Attacks using gem5

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

Haj Yahya, Pascal Benoit

► To cite this version:

Muhammad Awais, Maria Mushtaq, Lirida Naviner, Florent Bruguier, Jawad Haj Yahya, et al. De-coding Attack Behaviors by Analyzing Patterns in Instruction-Based Attacks using gem5. RSP 2024 - IEEE International Workshop on Rapid System Prototyping, Oct 2024, North Carolina, United States. pp.1-6, 10.1109/RSP64122.2024.10871078 . hal-05160886v2

HAL Id: hal-05160886

https://telecom-paris.hal.science/hal-05160886v2

Submitted on 23 Jul 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
Decoding Attack Behaviors by Analyzing Patterns
in Instruction-Based Attacks using gem5

Muhammad Awais

Comelec, Telecom-Paris

Institut Polytechnique de Paris

19, place Marguerite Perey.

Palaiseau, France

Maria Mushtaq

Comelec, Telecom-Paris

Institut Polytechnique de Paris

19, place Marguerite Perey.

Palaiseau, France

Lirida Naviner

Comelec, Telecom-Paris

Institut Polytechnique de Paris

19, place Marguerite Perey.

Palaiseau, France

Florent Bruguier

Lirmm, CNRS

University of Montpellier.

161 rue Ada 34095 Montpellier.

Montpellier, France

Jawad Haj Yahya

Rivos Ins

3315 Scott Boulevard

Santa Clara.

USA

Pascal Benoit

Lirmm, CNRS

University of Montpellier.

161 rue Ada 34095 Montpellier.

Montpellier, France

**Abstract**—The diversity of Instruction Set Architectures (ISAs), each with its unique constraints and optimization strategies, presents significant opportunities and challenges in processor design. Modern processor vendors exploit these ISAs to enhance security, reliability, and performance. Recent security vulnerabilities, notably Spectre and Meltdown, have highlighted the critical need for robust hardware security measures. In this paper, we employ gem5, a state-of-the-art cycle-accurate simulation tool, to simulate the Spectre attack. We developed and modified scripts for both x86 and ARM architectures to ensure compatibility with gem5 version 23.1. Our simulation setup involved running attack scenarios under various configurations to gather comprehensive data on cache misses, cache hits, mispredicted branches, and level 2 cache hits and misses. In the simulation, we analyzed the trace files generated by gem5, utilizing a range of debug flags such as Exec for disassembly (dasm) insights. By detailed analysis of cache and branch prediction using detailed debug data revealed by gem5 traces, we identify some specific attack patterns that are useful for automating the detection of the attacks. Our future work aims to expand this analysis to include additional attack vectors and find more attack patterns, thereby strengthening our attack pattern recognition capabilities.

***Index Terms***—Hardware Security, Embedded Systems, Hardware Attacks, Attacks Simulation, Attacks Patterns.

# I. INTRODUCTION

To optimize instruction execution, modern processors employ speculative execution. This technique allows processors to execute instructions without knowing the exact future instruction stream. For instance, processors execute instructions out-of-order [8] and may encounter instructions with conditional branches. In such cases, the processor preserves the current execution state in the register state and speculatively predicts the subsequent paths. If the prediction is correct, the results of the speculative execution are committed,

thereby optimizing instruction execution. However, if the prediction is incorrect, the processor discards the speculative results, restores the execution state from the register state, and resumes the correct execution path. Branch instructions that are mispredicted are known as transient instructions, identified by the branch predictor [12]. During transient execution, some information is temporarily left in the micro-architecture before the register state is restored. The Spectre attack [7] exploits these side channels to access sensitive protected data. Since its disclosure in 2018, numerous variants of this attack have been discovered, targeting various processors.

In this paper, we simulate transient execution attacks on two distinct Instruction Set Architectures (ISAs): x86 and ARM, both of which support speculative execution. We employ gem5 [11], a state-of-the-art, cycle-accurate simulator widely used in micro-architectural research, for our simulations. Our objective is to identify and analyze the execution patterns of instructions on these micro-architectures, understand their behavior under attack, and subsequently create a dataset of these patterns for further development of predictive tools. This constitutes the primary contribution of our study:

1) Our research investigates the resilience of micro-architectural designs against various attack vectors. We systematically analyze the impact of architectural modifications on the susceptibility to these attacks, providing a comprehensive assessment of the security implications in Section IV.

2) In Section V and Section VI, we discuss the configuration of gem5, the execution of the attacks, the associated Python scripts, the binaries, and the cross-compilation process.

3) We identify instruction execution patterns conducive to

This work is part of the SCAMA (Secure-by-Design Computing Against Microarchitectural Attacks) funded by the French National Research Agency (ANR).
the automatic prediction of transient execution attacks. This is achieved through detailed simulation and analysis of these attacks, as discussed in Section VII.

## II. BACKGROUND

### A. Microarchitectural side-channel Attacks

Microarchitectural components such as the branch predictor [12], Out-of-Order Execution [8], Speculative Execution, Register Renaming, and the cache hierarchy in modern processors enhance performance by predicting future program behavior and storing shared data in the caches. These components maintain a state based on past program behavior, assuming that future behavior will be similar or related to past behavior.

When multiple programs execute on the same hardware, either concurrently or via time-sharing, changes in the microarchitectural state caused by one program's behavior may affect other programs. This interaction can lead to unintended information leaks from one program to another.

Initial microarchitectural side-channel attacks exploited timing variability and leakage through the L1 data cache to extract keys from cryptographic primitives. Over the years, similar channels have been demonstrated in multiple microarchitectural components, such as lower-level caches and branch history.

### B. Out-of-order Execution

An *out-of-order* execution of instructions maximizes the utilization of processor components by allowing instructions to be executed in parallel, sometimes even before preceding instructions. Modern processors handle micro-operations (micro-ops) internally, meaning that instructions from the ISA are decoded into micro-ops [4]. Once all preceding instructions are completed, the instruction is retired, the register state is committed, and the buffer space is freed, ensuring that the instruction is retired in the execution order of the program.

### C. Branch Prediction

In an Instruction Set Architecture (ISA), there are various types of instructions such as `[ADD`, `CMP`, `MOV`, `JG`, and `JMP`]. Each instruction type serves a specific purpose. For instance, data transfer instructions like `[MOV]` and arithmetic instructions like `[ADD]` perform distinct operations.

Branch instructions direct the program flow and can be conditional or unconditional. For example: `[ADD eax, 5]`, `[CMP eax, 10]`, `[JG LABEL1]`

In this sequence, `[JG]` (Jump if Greater) is a conditional branch that directs the flow to `LABEL1` if the value in `eax` is greater than 10. Conversely, unconditional branches like `JMP END` always redirect the execution flow to the specified address without any condition.

Modern processors employ sophisticated branch prediction mechanisms to enhance performance. The Branch Target Buffer (BTB) stores addresses of recently executed branch instructions, enabling effective prediction of future instruction paths. Branch instructions can be categorized into direct and indirect branches, both capable of altering the execution path.

Additionally, the Return Stack Buffer (RSB) [4] maintains the return addresses of recently executed instructions, aiding in accurate prediction of return instructions. If a branch prediction error occurs, the processor stalls the speculative execution and relies on the BTB as a fallback mechanism to correct the execution flow.

### D. The CPU Cache Hierarchy

Modern processors have multiple cores, and their speed relative to main memory is significantly higher. To reduce the latency between the processor and the memory, cache memory was introduced. Cache memory, which is located inside the CPU chip, is faster than main memory but also more expensive. The cache hierarchy is typically divided into three to four levels: L1, L2, and L3 (often referred to as the Last Level Cache or LLC). In some modern processors with multiple CPU cores, the LLC is shared among these cores and linked to the main memory for fetching instructions and data. This sharing of the LLC can lead to cache hazards and cache-based side-channel attacks, such as Flush+Reload.

When the processor finds the required instruction or data in the cache, a *cache hit* occurs; if not, a *cache miss* happens. The internal structure of the cache depends on the microarchitecture. Cache lines, which store data from memory, consist of 32 to 64 consecutive bytes used for load (*load operation*) and flush (*flush operation*) operations. A fixed number of lines are grouped to form *cache sets*, which correspond to the cache *associativity*. The sharing of L1, L2, and LLC depends on the CPU architecture; typically, L1 is *private* to each CPU core, while L3 is *shared* across CPU cores.

In an *inclusive* cache hierarchy, data present in a lower-level cache (e.g., L1) is also present in all higher-level caches (e.g., L2, L3). Conversely, in an *exclusive* cache hierarchy, data is stored in only one level of the cache hierarchy at a time. If a piece of data is in the L1 cache, it is not present in the L2 or L3 caches. When data is moved from one level to another, it is typically removed from the original level.

## III. RELATED WORK

Recent advancements in the automated discovery of microarchitectural side channels have been significantly contributed by Danila Weber in 2021. Their work primarily focuses on the x86 architecture, where they systematically identify combinations of instructions within the ISA that may lead to side channels. The methodology involves collecting all instructions in the ISA and generating instruction triples
in the triples generation stage. These triples are then executed to analyze their timing characteristics, followed by clustering to determine the presence and type of side channels. This comprehensive analysis was conducted across five different CPUs, as detailed in [14]. The study successfully identified instruction triples forming side channels such as Flush+Reload [16], Flush+Flush [6], Flush+Prefetch [5], and BranchScope [3].

In contrast, the work utilizing the gem5 simulator is relatively sparse, given the simulator's ongoing development phase. Our study builds upon the work of Low-Power, detailed in a blog post [9], which illustrates how the Spectre attack exploits branch predictors and compiler optimizations, and how out-of-order processors perform speculative execution. For reproducing these attacks, we adhered to the gem5 documentation [10]. For ARM processor simulation, we initially followed the work of Endo et al. [2], also Pierre Ayoub [1] simulated the Cortex-A8 processor, although it is outdated and incompatible with the current version of gem5, necessitating modifications to the implementation of the Cortex-A8 architecture.

By integrating and extending these methodologies, our research aims to deepen the understanding of microarchitectural side channels and enhance the tools available for their analysis and mitigation.

## IV. GEM5 AND EXPERIMENT SETUP

gem5 is a robust and flexible simulation framework extensively used in computer architecture research. It enables researchers and developers to model and simulate computer systems, offering valuable insights into system performance, architectural innovations, and hardware-software interactions.

gem5 supports a wide range of computer architecture simulations, from simple single-core systems to complex multi-core and heterogeneous systems. Its highly modular structure allows for easy customization and extension to meet specific research needs. gem5 can perform both full-system (FS) simulations, which model the entire hardware and software stack, and syscall emulation (SE), which focuses on the application level. It supports various instruction set architectures (ISAs), including x86, ARM, SPARC, MIPS, and RISC-V, making it versatile for different research types.

Detailed memory system modeling, including cache hierarchies, memory controllers, and interconnects, allows for comprehensive memory system studies. Additionally, gem5 integrates seamlessly with other tools and frameworks, such as GPGPU-Sim for GPU modeling and McPAT for power modeling.

To set up gem5 for the simulation we utilize the `aarch64-linux-gnu-gcc` cross-compilers to generate a binary executable file for the attack vector. Following

<figure><img src="image_2.png" /><figcaption>Fig. 1. Methodology: Reproducing attack library, cross-compile for Aarch64 ARM, generate Python scripts, run gem5 simulation, and analyze traces.</figcaption></figure>

compilation, we create configuration scripts in Python for gem5. These scripts establish the interconnects between the cache and processors, utilizing out-of-order (O3) processors [8] with the LTAGE branch predictor [15]. To observe the behavior of the attacks, we configure a two-level cache hierarchy: a Level-one data cache, a Level-one instruction cache, and a Level-two cache, the configuration of the caches are listed in Table I.

We then dump the simulation traces into a file named `trace.out`, which details cache hits, cache misses, cache line accesses, and flushes. By analyzing these traces, we examine the behavior and patterns of the attacks. We employ the Konata tool for the graphical visualization of each trace entry, providing a pipeline view that helps decode the behavior of cache-based side-channel attacks [16] and transient execution attacks [7]. This analysis will inform the development of tools for the automatic detection of these attacks.

The experimental environment was configured on a system equipped with a 12th Gen Intel® Core™ i7-12700H processor, featuring 20 logical CPUs. The cache hierarchy includes L1d cache of 544 KiB (distributed across 14 instances), L1i cache of 704 KiB (distributed across 14 instances), L2 cache of 11.5 MiB (across 8 instances), and an L3 cache of 24 MiB (single instance). The system is further equipped with 16 GB of DDR5 RAM.

## V. X86 SPECTRE ATTACK TRACES

To reproduce the Spectre attack and analyze the resulting traces, we first create a Python script. The architecture of gem5 components involves two languages: the core of the sim-objects is written in C++, while the simulation script must be written in Python. In our setup, we did not modify the core of gem5; instead, we created custom cache configurations to compare results under various conditions.

For reproducing Spectre Variant 1, which exploits conditional branches, we set up a scenario where a function or library receives a signed integer *x* from an untrusted source. The running process has access to an array of unsigned bytes, `array1`, of a certain size `array1_size`, and a second array, `array2`, of size 1MB, as illustrated in Fig. 2.

There are two primary steps in the attack: the first is the mistraining of the conditional branch. This involves creating a covert channel by flushing all elements of `array2` from
```
if (x < array1_size)
    y = array2[tarray1[x]] * 4096;
```

<caption>Fig. 2. Conditional branch used in the Spectre attack.</caption>

the cache, as part of the Flush+Reload technique. This is achieved by sending a malicious x value, such as x = &secret - array1, causing the processor to transiently execute the `array2[tarray1[x]]` memory access. The second phase involves recovering the bytes from this covert channel. We follow the implementation of the Spectre attack as described by Paul Kocher [7].

To create the Python script for the simulation in SE mode, we configured the system to use an out-of-order CPU with the LTAGE branch predictor. The simulation was set to timing mode, with the CPU clock frequency at 1 GHz and a power latency of 200 cycles. Additionally, we implemented a custom cache hierarchy as detailed in Table I.

<table><caption>TABLE I
CACHE CONFIGURATIONS FOR X86 SCRIPT</caption><thead><tr><th rowspan="2">Conf No</th><th rowspan="2">Caches</th><th rowspan="2">Assoc</th><th colspan="5">L1 Instruction cache, L1 Data cache and L2 Cache Configuration</th><th rowspan="2">Size</th></tr><tr><th>Tag Latency</th><th>Data Latency</th><th>Resp Latency</th><th>Mshrs</th><th>1 gts-per-mshr</th></tr></thead><tbody><tr><td rowspan="3">Conf 1</td><td>L1 Ins</td><td>2</td><td>2</td><td>2</td><td>2</td><td>2</td><td>4</td><td>64KB</td></tr><tr><td>L1 Data</td><td>2</td><td>2</td><td>2</td><td>2</td><td>2</td><td>4</td><td>64KB</td></tr><tr><td>L2 Cache</td><td>4</td><td>4</td><td>4</td><td>2</td><td>4</td><td>8</td><td>128KB</td></tr><tr><td rowspan="3">Conf 2</td><td>L1 ins</td><td>4</td><td>2</td><td>2</td><td>2</td><td>4</td><td>8</td><td>32KB</td></tr><tr><td>L1 Data</td><td>4</td><td>2</td><td>2</td><td>2</td><td>4</td><td>8</td><td>128KB</td></tr><tr><td>L2 Cache</td><td>8</td><td>4</td><td>4</td><td>2</td><td>8</td><td>16</td><td>256KB</td></tr><tr><td rowspan="3">Conf 3</td><td>L1 ins</td><td>8</td><td>2</td><td>2</td><td>2</td><td>4</td><td>8</td><td>64KB</td></tr><tr><td>L1 Data</td><td>8</td><td>2</td><td>2</td><td>2</td><td>4</td><td>8</td><td>256KB</td></tr><tr><td>L2 Cache</td><td>16</td><td>4</td><td>4</td><td>2</td><td>8</td><td>16</td><td>1024KB</td></tr></tbody></table>

Table I shows the detailed caches configuration used for the simulation.

<figure><img src="image_3.png" /><figcaption>Fig. 3. X86 Spectre: Cache configuration Results with the correct predictions.</figcaption></figure>

The DRAM used in our setup is a DDR3 memory module operating at 1600 MT/s, with 8 memory chips each 8 bits wide. The size of the DRAM for simulating the script is 512MB. The simulation results for three configurations (Conf 1, Conf 2, and Conf 3) on the x86 architecture are shown in Figure 3.

Each configuration demonstrates various cache performance metrics over a consistent simulation time of $1 \times 10^{11}$, we observe that (Conf 1), the metrics displayed include L1 Data (L1D) cache misses, L1D cache hits, Instruction Branch Prediction (IBP) hits, IBP misses, L2 cache misses, and L2 cache hits. These metrics provide a comprehensive view of

the cache performance and branch prediction accuracy for this configuration.

The (Conf 2) follows a similar structure to (Conf 1), monitoring the same set of metrics—L1D misses and hits, IBP hits and misses, L2 misses, and L2 hits. This setup allows for a comparative analysis of cache performance and branch prediction accuracy between the two configurations under identical simulation conditions. On the other hand the (Conf 3) maintains the same metrics as the previous configurations, recording L1D misses and hits, IBP hits and misses, L2 misses, and L2 hits. This consistency in monitored metrics across all three configurations facilitates a detailed examination of how cache performance and branch prediction accuracy evolve across different configuration setups under the same simulation time frame.

Each graph in Figure 3 shows how performance metrics vary across different configurations, offering insights into cache efficiency and the effectiveness of branch prediction on the x86 architecture.

## VI. ARM SPECTRE ATTACK TRACES

To reproduce the Spectre attack for the ARM architecture, we initially followed the work of Endo et al. [2]. However, their approach is not compatible with the current version of gem5 (version 23.1) due to significant changes in the simulation framework. Specifically, the Master port has been renamed to `mem_side_ports`, the Slave port to `cpu_side_ports`, and the `memory_outgoingBridge` has been removed from the system simulation object.

For our implementation in gem5 23.1, we selected the `DerivO3CPU` with timing mode to obtain cycle-accurate traces. In gem5, there is no straightforward two-level global-based predictor available. Only the TournamentBP and Bi-Mode predictors are global-based. The TournamentBP also incorporates local prediction, while the Bi-Mode predictor separates mostly-taken and mostly-not-taken branches into two separate Pattern History Tables (PHTs). Since our Spectre attack targets branches trained to be mostly taken, the Bi-Mode predictor is the most appropriate choice for our simulation.

The pipeline configuration for the `DerivO3CPU` processor includes a fetch width of 4 (128 bits for 32-bit instructions), a decode width of 3, a commit width of 3, a dispatch width of 5, and an issue width of 8. For the cache hierarchy, we used `ARM_A72_CacheL1I` with a size of 64KB, `ARM_A72_CacheL1D` with a size of 128KB, and `ARM_A72_CacheL2` with a size of 1024KB.

To create the binary executable of the Spectre attack compatible with the ARM architecture, we used the `aarch64-linux-gnu-gcc` cross-compiler with the
`march=armv8-a` flag. After compiling the binary, the next step was to create a disk image containing this workload. We used disk images provided by `gem5` resources, which include the Linux kernel. To add the workload to the disk image, we mounted `linaro-minimal-aarch64.img` (available at [13]) into `/mnt/` using the Linux mount utility. We then navigated to the `/mnt/home/root` directory and transferred our workload using the Linux `mv` command. After incorporating the workload into the disk image, we initiated the full-system simulation.

After initiating the Full system of the ARM V8 we have to monitor the simulation, the terminal is listening on the 3456 port, and we have to connect the m5 terminal to the port to access the terminal of the simulated system, after the booting process, we were inside the simulated system and then the spectre attack workload that we place inside the disk image, we ran it many times, as it was in the Full systems mode and the setup for the environment that we used are discussed in the section IV and get the traces of the simulation, the average time taken by 1 cycle of the simulation is 4 hours.

<figure><img src="image_4.png" /><figcaption>Fig. 4. ARM v8 Spectre: Cache configuration Results with the correct predictions.</figcaption></figure>

The graphs in Figure 4 corresponds to distinct configurations (`Conf 1`, `Conf 2`, and `Conf 3`) as listed in Table I for the ARM Full System (FS). For (`Conf 1`), the simulation time is $1 \times 10^{11}$. The displayed metrics include L1 Data (L1D) cache misses, L1D cache hits, branch instruction miss predictions (`BI Miss Pred`), L2 cache misses, and L2 cache hits. These metrics provide insights into the cache performance for the given simulation duration.

From the configurations the (`Conf 2`) extends the simulation time to $1 \times 10^{12}$, with metrics similar to those in (`Conf 1`), including L1D misses and hits, `BI Miss Pred`, L2 misses, and L2 hits. This setup allows for a comparative analysis of cache performance over a longer simulation period.

Configuration 3 (`Conf 3`) further extends the simulation time to $1 \times 10^{13}$. The metrics recorded for this configuration are consistent with the previous ones, encompassing L1D misses and hits, `BI Miss Pred`, L2 misses, and L2 hits. This consistency facilitates the assessment of how cache performance metrics evolve over extended simulation

durations.

Each configuration illustrates the number of misses and hits for both the L1 Data cache (L1D) and the L2 cache, along with branch instruction miss predictions (`BI Miss Pred`) over increasing simulation times. The graphs in Figure 4 demonstrate the variations in performance metrics across different configurations and simulation periods, providing insights into cache efficiency and prediction accuracy within the ARM Full System simulation.

## VII. TRACE ANALYSIS

`Gem5` provides the capability to visualize trace files and debug workloads using predefined flags such as `Exec`, `LTage`, `Fetch`, `HWPrefetch`, `MemoryAccess`, `O3PipeView`, and many other useful debug traces available for various analyses. Our study focuses on attack behavior, so we analyze trace files to identify attack patterns, specifically the sequence of memory access patterns, to create datasets for AI-based tools aimed at detecting and preventing system attacks.

To identify attack patterns, we use the m5 utility from `gem5`. First, we instrument the attack source code such that every successfully recovered byte triggers a function call that writes "byte recovered" to the trace file using `m5.write(1, 'byte recovered,15)`. Once the attack completes, we extract all m5 writes from the trace file. Analyzing these writes allows us to trace the pipeline of each recovered byte.

The detected patterns for the branch predictor and speculative instructions in the Spectre attack are illustrated in Figure 5 and Figure 6."

```
train_loop:
    mov rdx, [rax + rsi*4] ; Load array1[i] into rdx
    shl rdx, 0xC ; Multiply by 4096
    mov al, [rbx + rdx] ; Access array2[i]*4096]
    add rsi, 1
    cmp rsi, 100
    jl train_loop
```

<caption>Fig. 5. Branch Predictor training pattern x86</caption>

Figure 5 depicts the detected pattern obtained by analyzing the `trace.out` file using the debug flags `-debug-flags=Exec, LTage, Fetch, HWPrefetch, MemoryAccess, O3PipeView`. Our objective is to execute additional attacks and identify more patterns to enhance the training of the attack predictor.

Currently, we are attempting to run the `FLUSH+RELOAD` attack with the shared library in `gem5`'s full system mode. Future work will involve identifying additional attack patterns through similar detailed analysis.

This attack pattern involves several steps. First, the attacker clears the CPU caches to ensure accurate measurement of cache accesses. Next, the branch predictor is trained
```
mov rsi, secret_index ; Index that triggers out-of-bounds
rsi, array1_size ; Check bounds
jae skip ; Jump if out-of-bounds
mov rdx, [rax + rsi*4] ; Speculatively execute out-of-bounds
shl rdx, 0xC
mov al, [rbx + rdx] ; Acc array2(array1[secret_index]*4096]
skip
```

<caption>Fig. 6. Speculative Execution (Trigger) Pattern</caption>

by executing a predictable code sequence multiple times, conditioning the CPU to follow a specific branch outcome. Then, speculative execution is triggered with an index designed to cause an out-of-bounds memory access.

The provided assembly code snippet demonstrates this: the index `secret_index` is loaded into `rsi`, and if it is within bounds, speculative execution proceeds to access `array1[secret_index]`, shifts the result, and accesses `array2` at the calculated offset. Even if the access is out-of-bounds, speculative execution continues based on the trained branch predictor. After speculative execution, the attacker measures the access times to elements in `array2` to identify which part was cached during speculation.

By comparing access times against a threshold, the attacker can determine which memory access was faster, revealing the secret byte. Repeating this process allows the attacker to recover the entire secret data byte-by-byte, leveraging the CPU's speculative execution and cache side-channel vulnerabilities.

## VIII. CONCLUSION

In this paper, we present a novel approach to analyzing the behaviors of attacks within a simulated environment. We utilized transient execution attacks for the initial phase of our research, focusing on both x86 and ARM architectures. Our methodology involved generating configuration scripts for the gem5 simulator, accommodating both the x86 architecture and ARM architecture with necessary modifications for compatibility with the latest version of gem5, version 23.1.

Our key findings are the attack patterns that we present in the results, executed simulations under various configurations, and analyzed the trace files to identify attack patterns. The results of our simulations are presented, highlighting specific attack behaviors and attack patterns. Our future objective is to extend this research by running additional attacks to strengthen our attack pattern vector. Additionally, there is significant potential to reproduce cache-based attacks such as Flush+Reload and Prime+Probe, which we are actively exploring to further expand our attack vector.

## REFERENCES

[1] 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*, pages 15–20, 2021.

[2] F. A. Endo, D. Couroussé, and H.-P. Charles. Micro-architectural simulation of in-order and out-of-order arm microprocessors with gem5. In *2014 international conference on embedded computer systems: Architectures, modeling, and simulation (SAMOS XIV)*, pages 266–273. IEEE, 2014.

[3] D. Evtyushkin, R. Riley, N. C. Abu-Ghazaleh, ECE, and D. Ponomarev. Branchscope: A new side-channel attack on directional branch predictor. *ACM SIGPLAN Notices*, 53(2):693–707, 2018.

[4] A. Fog. The microarchitecture of intel, amd, and via cpus, May 2017. [Online]. Available: https://www.agner.org/optimize/microarchitecture.pdf.

[5] D. Gruss, C. Maurice, A. Fogh, M. Lipp, and S. Mangard. Prefetch side-channel attacks: Bypassing smap and kernel aslr. In *Proceedings of the 2016 ACM SIGSAC conference on computer and communications security*, pages 368–379, 2016.

[6] D. Gruss, C. Maurice, K. Wagner, and S. Mangard. Flush+ flush: a fast and stealthy cache attack. In *Detection of Intrusions and Malware, and Vulnerability Assessment: 13th International Conference, DIMVA 2016, San Sebastián, Spain, July 7-8, 2016, Proceedings 13*, pages 279–299. Springer, 2016.

[7] 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*, 63(7):93–101, 2020.

[8] J. Li, K. Tufte, V. Shkapenyuk, V. Papadimos, T. Johnson, and D. Maier. Out-of-order processing: a new architecture for high-performance stream systems. *Proceedings of the VLDB Endowment*, 1(1):274–288, 2008.

[9] J. Lowe-Power. Visualizing specter with gem5. Fri 01 June 2018. [Online]. Available: http://www.lowepower.com/jason/visualizing-spectre-with-gem5.html.

[10] J. Lowe-Power. Gem5 documentation, Sat 29 June 2024. [Online]. Available: https://www.gem5.org/documentation/.

[11] J. Lowe-Power, A. M. Ahmad, A. Akram, M. Alian, R. Amslinger, M. Andreozzi, A. Armejach, N. Asmussen, B. Beckmann, S. Bharadwaj, et al. The gem5 simulator: Version 20.0+. *arXiv preprint arXiv:2007.03152*, 2020.

[12] S. Mittal. A survey of techniques for dynamic branch prediction. *Concurrency and Computation: Practice and Experience*, 31(1):e4666, 2019.

[13] G. C. Utilities. Gem5 arm fs binaries, Sat 29 June 2024. [Online]. Available: https://www.gem5.org/documentation/general_docs/ fullsystem/guest_binaries.

[14] D. Weber, A. Ibrahim, H. Nemati, M. Schwarz, and C. Rossow. Osiris: Automated discovery of microarchitectural side channels. In *30th USENIX Security Symposium (USENIX Security 21)*, pages 1415–1432, 2021.

[15] N. Wu and Y. Xie. A survey of machine learning for computer architecture and systems. *ACM Computing Surveys (CSUR)*, 55(3):1–39, 2022.

[16] Y. Yarom and K. Falkner. {FLUSH+ RELOAD}: A high resolution, low noise, 13 cache {Side-Channel} attack. In *23rd USENIX security symposium (USENIX security 14)*, pages 719–732, 2014.