SOURCE ARCHIVE
EXTRACTED CONTENT
130,183 chars P ORT RUSH: Detect Write Port Contention
Side-Channel Vulnerabilities via Hardware Fuzzing
Peihong Lin, Pengfei WangB, Lei Zhou, Gen Zhang, Xu Zhou, Wei Xie, Zhiyuan Jiang, Kai LuB
National University of Defense Technology
{phlin22, pfwang, zhoulcs, zhanggen, zhouxu, xiewei, jzy, kailu}@nudt.edu.cn
Abstract—CPU vulnerabilities pose ongoing security challenges Evict+Time [32] leverage subtle differences in cache access in modern CPU architectures. Among the CPU vulnerabilities, times to extract sensitive information from victim processes. write port contention—caused by multiple functional modules As a result, most existing detection and mitigation efforts, simultaneously competing for a limited number of shared write ports—remains insufficiently studied. In this paper, we study including Kernel Page-Table Isolation [20] and various cache write port contention side-channel vulnerabilities in CPUs and partitioning and randomization techniques [18], [38], have propose PORTRUSH, a novel fuzzing framework designed to focused primarily on defending against cache-based side chan- detect and validate such vulnerabilities at the register-transfer nels. level (RTL). First, PORTRUSH constructs a Write Request Graph In contrast, port contention side-channel attacks, especially (WRG) to statically identify potential write port contention instances by modeling write paths and priority relationships those caused by write port contention, have received far less among functional modules that target shared storage elements. attention from the research community and industry. In modern Second, within the WRG, PORTRUSH implements a Hierarchical CPUs, different functional modules (i.e., write entities) often Aggregation and Decoding method to efficiently detect write port share a limited number of write ports to access storage ele- contention by monitoring relevant hardware signals across design ments such as register files or caches. When multiple entities hierarchies. Third, PORTRUSH employs a Contention-guided Hardware Fuzzing approach to trigger write port contention issue write requests in the same cycle that exceed the number and automatically combine contention-triggered instruction se- of available write ports, contention occurs. To arbitrate access, quences with transient execution attack patterns, enabling vali- most CPUs employ priority-based mechanisms, such as fixed- dation of write port contention side-channel vulnerabilities. We priority or first-come-first-served policies [1], [5], [43], which evaluate PORTRUSH on three RISC-V CPUs (BOOM, NutShell, can cause lower-priority instructions to be delayed by higher- and Rocket Core) and demonstrate its effectiveness in identifying and triggering write port contention. Furthermore, we validate priority ones, resulting in observable timing differences. that the discovered vulnerabilities can be exploited in realistic Recent works [2], [12], [23] have shown that timing dif- write port contention attack scenarios. Based on these vulnera- ferences, when combined with transient or speculative ex- bilities, we present two novel attack vectors: Birgus-variant, ecution, can form the basis of powerful side-channel at- which exploits contention at the physical register file in the tacks. Specifically, attackers can craft gadgets that deliberately Reorder Buffer, and MSHRush, which leverages contention be- tween the Load/Store Unit (LSU) and Miss Status Handling trigger write port contention by manipulating control-flow Register (MSHR) at the L1 data cache to induce secret-dependent or data dependencies, causing high-priority instructions to execution delays. We also propose mitigation strategies for CPU compete with low-priority victim instructions for write port developers to prevent such vulnerabilities. access. If the victim’s execution time varies depending on I. INTRODUCTION secret-dependent conditions (e.g., whether a specific secret The increasing complexity of modern CPU architectures has bit matches an attacker-controlled probe), attackers can infer led to the emergence of various micro-architectural vulner- sensitive information based on measured timing differences. abilities, including speculative execution attacks [14], [25], Write port contention that can be exploited in this manner is [27], [29] and privilege escalation exploits [6], [8], which termed write port contention side-channel vulnerability. pose serious threats to both hardware and software security. Despite their threat, existing vulnerability detection ap- Among these, cache-based side-channel attacks have been proaches, including both static analysis (e.g., formal ver- the most widely studied and exploited in practice. Attacks ification [17], [22]) and dynamic testing (e.g., hardware such as FLUSH+RELOAD [21], PRIME+PROBE [31], and fuzzing [13], [16], [24], [28], [35], [39]), do not specifically target write port contention side-channel vulnerabilities. As B Corresponding author(s). a result, hidden instances of write port contention may go undetected, and it remains unclear whether and how these cases can be exploited in real-world attacks. In this paper, we present PORTRUSH, a novel hardware fuzzing framework designed to detect write port contention Network and Distributed System Security (NDSS) Symposium 2026 side-channel vulnerabilities. PORTRUSH combines four es- 23-27 February 2026, San Diego, CA, USA sential stages: (i) static identification of potential write port ISBN 979-8-9919276-8-0 contention instances, (ii) dynamic monitoring of contention https://dx.doi.org/10.14722/ndss.2026.240587 www.ndss-symposium.org
instances, (iii) triggering write port contention through a hensive understanding of their root causes and impact.
hardware fuzzing approach, and (iv) automated validation • We design and implement PORTRUSH, a novel fuzzing
by combining write port contention with transient execution framework to detect write port contention side-channel
attack patterns to assess the feasibility of real side-channel vulnerabilities. PORTRUSH is evaluated on three real-
attacks. Moreover, based on the detection and validation of world RISC-V CPUs (BOOM [43], NutShell [15], and
these vulnerabilities, we propose mitigation strategies for CPU Rocket Core [5]), identifying 177 distinct instances of
designers. potential write port contention and successfully triggering
However, realizing this framework presents several chal- 35 of them. Among these, three instances are verified to
lenges. (i) Statically identifying potential write port con- be exploitable in conjunction with transient or speculative
tention is challenging. Modern RISC-V CPUs [10], [15], execution as side-channel attack vectors.
[43] feature deeply nested, modular structures with complex • We validate the feasibility of write port contention side-
arbitration logic, making it difficult to extract all write paths channel attacks. By combining contention-triggering in- and priority relationships among write entities for comprehen- struction sequences with transient or speculative exe- sive static analysis. (ii) Real-time monitoring of write port cution patterns, we discover three side-channel attack contention is non-trivial. Out-of-order execution in modern vectors, including two novel variants (MSHRush on CPUs [4], [15], [43] decouples programmed instruction order, BOOM and Birgus-variant on NutShell) and the making it infeasible to monitor which entities issue write known Spectre-STC attack on BOOM. Compared requests (i.e., detect write request behaviors) based on instruc- to traditional cache-based attacks, write port contention tion order. Thus, PORTRUSH must monitor internal signals at side-channel attacks enable information leakage even in runtime, but the large signal space makes it challenging to processors with secure or partitioned caches. efficiently identify relevant signals and design scalable, low- overhead detection mechanisms. (iii) Dynamically triggering II. BACKGROUND and validating write port contention is challenging. Current Hardware Fuzzing. Hardware fuzzing is an automated dynamic validation approaches, such as hardware fuzzing [23], dynamic testing technique designed to explore the functional [24], [39], are not specifically designed to target write port boundaries of hardware designs and identify potential vulnera- contention. These methods lack contention-aware feedback bilities by iteratively generating and executing test cases [13], and do not guide the generation of simultaneous write requests [16], [24], [28], [35], [39]. Typically, the hardware fuzzer gen- from multiple entities. Moreover, they do not support the erates a set of test cases, known as seeds, which are executable automatic combination of triggered contention instances with programs composed of instruction sequences. These seeds are transient execution attack patterns, thus failing to validate then executed on the DUT using hardware simulation tools, the exploitability of port contention through real side-channel such as open-source Verilator [34] or commercial simulators attacks. such as Synopsys VCS [9]. During execution, coverage feed- PORTRUSH solves the aforementioned challenges by fol- back is collected in one of two ways: actively by instrumenting lowing three approaches. (i) We propose a Write Request the DUT with dedicated logic to monitor specific behaviors Graph (WRG) abstraction that models arbitration logic and or passively via built-in metrics provided by the simulation priority relations in RTL, enabling automated extraction of all tools [24], [28]. Common coverage metrics include the finite write paths and their associated priorities, thereby identifying state transitions of control registers (i.e., register coverage) potential write port contention (§IV-B). (ii) We design a [13], [24], multiplexer pattern coverage [28], or accessed Hierarchical Aggregation and Decoding mechanism that register states [35]. These coverage insights guide further test collects relevant signals across module boundaries and effi- case mutations, such as bit flips or instruction substitutions, ciently reconstructs write request behaviors and contention in- strategically driving the testing towards improved hardware stances in real time (§IV-C). Write port contention is detected design coverage. when the number of write requests issued by write entities To further enhance vulnerability detection, differential test- exceeds the number of available write ports associated with the ing and assertion-based verification are often integrated into target storage element. (iii) We develop a Contention-guided hardware fuzzing workflows. Differential testing identifies Hardware Fuzzing approach that automatically triggers write vulnerabilities by comparing outputs or states (e.g., regis- port contention by maximizing write request coverage, actively ter values, memory consistency, exception handling) of the generating simultaneous requests from multiple entities, and DUT against those of a known-correct golden reference seamlessly combining these with transient execution attack model [23], [24], [39]. Assertion-based verification encodes patterns to validate write port contention side-channel attacks expected hardware properties as assertions within the DUT, (§IV-D). and violations of these assertions indicate potential vulnera- In summary, we make the following contributions: bilities [13], [30]. However, despite the effectiveness of these • We conduct the study of write port contention side- techniques in detecting hardware vulnerabilities, systematic channel vulnerabilities in CPU microarchitectures. Our analysis of hardware fuzzing methods targeting write port work covers static identification, monitoring, triggering, contention remains limited. On one hand, current hardware and validation of these vulnerabilities, providing compre- fuzzing techniques lack appropriate methods to monitor write
2
Functional Modules 1 attacker:
2 rdcycle x10
CSR (1) ALU (2) DIV (3) …… 3 call victim
4 rdcycle x11
5 sub x11, x11, x10
req 1 req 2 req 3 6 /* Use timing difference in x11 to infer secret bit */
Issue 7 victim:
Same 8 ...
Arbiter Cycle 9 /* low-priority div is data-dependent on beq branch */
10 div x18, x15, x14
11 ...
Port 12 /* Branch predictor misprediction setup */
13 beq x16, x18, L1 /* Branch mispredicted as not taken */
Register File 14 transient:
15 /* Begin transient window */
16 la x19, secret /* Load address of secret */
17 ld x20, 0(x19) /* Load secret value */
Write Requests > Write Port 18 andi x20, x20, 0x1 /* Extract secret bit */
(req 1, req 2, req 3) (Port ) 19 beqz x20, L1 /* If secret bit = 0, skip alu storm */
20 alu_storm:
21 /* multiple alu instructions within 1 cycle */
22 add x24, x15, x14
Port Contention ! 23 ...
24 L1:
Fig. 1: An illustration of the write port contention 25 ...
26 ret
request behaviors, which would provide useful feedback for Listing 1: An example of combining a speculative attack with
optimizing mutation strategies. On the other hand, existing write port contention to leak secret information
assertion-based verification approaches are not suited to detect
write port contention side-channel vulnerabilities, as these [Line 2] Victim & Time T0
are essentially non-functional, resource-related concerns rather
than functional correctness errors. [DIV and ALU Storm execute concurrently]
Timing Side-channel Attacks. Time side-channel attacks [Line 10] Long-latency Division (OOO window)
are a powerful form of information leakage that exploits
subtle timing differences observed during a system’s execution [Line 13] Mispredicted Branch
to uncover secret or sensitive data. Typically, these attacks
analyze measurable differences in execution time stemming [Lines 16-18] Load Secret & Extract Secret Bit
from the internal microarchitectural behavior of CPUs. One [ALU Storm creates write port contention]
prominent category of timing side-channel exploits is cache- (blocking DIV write)
based attacks, such as PRIME+PROBE [31], Evict+Time [32], [Line 19] if (secret bit == 1)
and FLUSH+RELOAD. Classical examples, such as Spec-
tre [27] and Meltdown [29], exploit speculative execution by [Lines 20-22] ALU Storm: multiple ALU instrs
manipulating cache states to leak sensitive information. More
recent studies have revealed timing side channels based on
port contention within CPU functional modules. For example, [Line 4] End & Time T1, ΔT = T1 - T0
the attack named SMoTherSpectre [12] leverages contention (ΔT is larger if contention)
on CPU execution ports. By strategically causing a conflict Fig. 2: Motivation example
at the hardware execution-resource level during speculative
execution, adversaries measure timing differences induced by fixed-priority scheme, each module is assigned a predefined
resource contention to reconstruct sensitive information. priority, and the highest-priority request is served first, while
III. MOTIVATION lower-priority requests are deferred to subsequent cycles.
However, this arbitration introduces timing discrepancies:
- Causes of Write Port Contention: Write port contention lower-priority or later-arriving write-eliciting instructions may arises in modern CPUs when, within a single clock cycle, the experience observable delays when they contend for the same number of write requests issued by functional modules (e.g., port as higher-priority instructions. Crucially, these timing CSR, ALU, and DIV) exceeds the number of available shared delays are not just a performance artifact—they can be ex- write ports to storage elements such as register files, memory, ternally observed and exploited by attackers. By carefully or caches. This situation is common in practical designs [1], orchestrating contention, an attacker can induce measurable [5], [15], [43], where cost and area constraints often limit the timing differences in the execution of victim instructions, number of write ports. To resolve such contention, designers thereby constructing side-channel attacks that leak sensitive implement arbitration mechanisms, such as fixed-priority or information via write port contention. first-come, first-served (FCFS) schemes, that determine which 2) Security Risks of Write Port Contention: Write port con- request is granted access in each cycle. For example, in a tention introduces exploitable security risks when an attacker 3 STATIC ANALYSIS Priorities VULNERABILITY VALIDATION Graph Selection Signal Analyzer 2 elements Aggregation Target values Engine 4 Target Signal Sequence Values Write Write Request Request Graph Behaviors Diagnoser 1 Monitor Source Code DUT 3 5 6 Write Port of DUT Instrument 4 Identified Signal Contention Sequence Values Signal PSO Optimizer Seed Corpus Mutator Signal Decoder Exploration Exploitation Seeds Input Mutation SimInput Sequences Transient 9 3 Execution add x1,x2,x3 addx1,x2,x3 1 Interpretation 2 Attack div x3,x4,x5 divx3,x4,x5 Data DUT Pattern Can be Port ..... ..... Contention 8 Optimized Simulation Side Channel? Strategy Exploitable Seeds PSO Optimizer Register Behavior Coverage Coverage Opcodes Distribution + + Write Port Contention HARDWARE Instruction Length 7 Side-channel Vulnerability! FUZZING Instruction Order Fig. 3: The overview of PORTRUSH.
can deliberately delay lower-priority instructions through instructions are eventually squashed after branch misprediction bursts of high-priority instructions, resulting in measurable is resolved, the contention they cause delays the write-back timing differences. This timing side-channel becomes a practi- of the division result. This microarchitectural delay persists cal vulnerability when combined with transient or speculative and can be detected by the attacker through precise timing execution attack patterns, enabling attackers to leak sensitive measurements of the victim function’s execution. This case information that would otherwise be protected by software- demonstrates that write port contention, when combined level checks. with transient execution attack patterns, creates a novel In a typical attack scenario, the victim function contains and exploitable side-channel vulnerability. a long-latency, low-priority division instruction div (Line 10) whose result determines the outcome of a conditional IV. DESIGN OF PORTRUSH branch (Line 13). As shown in Listing 1 and Figure 2, A. A High-Level Overview the attacker first poisons the branch predictor to ensure the branch is mispredicted. When the attack is triggered, the CPU PORTRUSH detects write port contention side-channel vul- speculatively enters a transient window (Lines 14-23) before nerabilities by static identification, real-time monitoring, and the true branch outcome is known. During this window, the dynamic fuzzing combined with side-channel attack valida- victim function loads the secret (Lines 16-18) and checks tion. Specifically, PORTRUSH first extracts the Write Request whether a specific secret bit matches an attacker-controlled Graph to model arbitration and priority relations and identify probe value (Line 19). If the condition is met, the code potential write port contention instances (§IV-B). It then em- speculatively executes a burst of high-priority alu instructions, ploys a lightweight Hierarchical Aggregation and Decoding intentionally issuing multiple write requests to the register mechanism to monitor real-time write request behaviors and file and creating intense write port contention (Lines 20- write port contention instances (§IV-C). Third, a Contention- 23). The div instruction and the speculative alu instructions guided Hardware Fuzzing approach is introduced to automat- can overlap in execution due to the out-of-order scheduling ically trigger write port contention (§IV-D). Finally, write port capabilities of modern CPUs. Specifically, while div is still contention side-channel attacks are constructed by combining pending and its result is needed for the branch in Line 13, write port contention with transient execution. Contention the processor may speculatively execute instructions in the instances that can be exploited in this manner are validated transient window, such as the alu storm containing mul- as write port contention side-channel vulnerabilities. tiple alu instructions, before actual branch resolution. This As depicted in Figure 3, PORTRUSH comprises three behavior allows speculative alu instructions to contend for integrated modules: static analysis, hardware fuzzing, and the write port at the same time as the div is completing. As vulnerability validation. Blue numbers indicate steps in the a result, significant write port contention occurs only when static analysis phase, while red numbers indicate steps in the the secret bit matches the probe value. Although speculative hardware fuzzing phase.
4
Static Analysis and Monitoring Instrumentation. The to vj in the RTL. Each edge may be annotated with its Graph Analyzer extracts the WRG, calculates priorities of corresponding arbitration or selection condition. write entities, and identifies selection elements and their target The construction of the WRG includes three steps: values required for successful write requests. The Signal (1) Extracting the graph structure from the DUT. We Aggregation Engine then defines instrumentation rules to ag- first extract the necessary structural information directly from gregate selection signals, mapping each write request to a the DUT. All elements in the RTL design involved in write unique signal sequence (i.e., target signal sequence values). operations are identified as nodes in the graph, including 1) The map containing target signal sequence values is stored functional modules that generate write requests, 2) elements locally and retrieved during fuzzing to reconstruct and identify such as wires, registers, ports, and multiplexers that propagate write request behaviors. write requests, and 3) storage elements with write ports Hardware Fuzzing. The Seed Corpus of fuzzing is or- that receive write requests. Each directed edge in the graph ganized into two pools: the exploration pool and the ex- represents a possible data flow or control dependency between ploitation pool. The exploration pool leverages a dictionary these elements. derived from the RISC-V ISA [3], mapping valid opcodes to (2) Identification and simplification of write paths. their operand formats and enabling the generation of diverse Starting from each write entity in the DUT, we perform instruction templates. During exploration, the Mutator selects a depth-first search to enumerate all possible paths leading opcodes and fills in operand fields (e.g., rd, rs, imm), without to the storage elements. During this process, only elements strictly constraining memory or control flow targets, allowing directly involved in arbitration, such as selection elements PORTRUSH to explore a wide range of architectural excep- with multiple inputs and a single output (e.g., multiplexers, tions (e.g., misaligned accesses and out-of-bounds reads and priority arbiters), are retained in the graph. This results in writes). During exploitation, the Mutator selects seeds from a simplified representation that highlights the essential arbi- the exploitation pool to construct new instruction sequences tration logic, filtering out micro-events or transitions that do that can trigger write port contention. not impact write port contention. Formally, a path path = < Vulnerability Validation and Feedback. During DUT (e, s1), (s1, s2), . . . , (sn, se) > denotes the sequence of nodes simulation, the signals of selection elements are aggregated and edges from a write entity e to a storage element se, with and encoded into signal sequences to the Signal Decoder. intermediate nodes si representing only selection or arbitration The Signal Decoder reconstructs write request behaviors from logic. the signal sequences, and the Diagnoser identifies contention (3) Normalization of multi-input selection elements. In instances. The exploitability is assessed by correlating detected RTL designs, write arbitration is typically implemented using contention with transient execution attack patterns, and con- selection elements such as multi-input priority arbiters, mul- tinuously feeding coverage and contention information back to tiplexers, or priority encoders. To facilitate priority extraction the PSO optimizer. This feedback loop allows the optimizer and analysis, each multi-input selection element is normalized to adapt its fuzzing strategies, such as opcode selection, by decomposing it into a cascade of two-input selection instruction sequence length, and instruction ordering, thereby elements. Given a selection element with inputs I1, I2, . . . , Ik enabling the automated discovery of write port contention side- (k ≥ 3) and a priority order I1 > I2 > . . . > Ik, we construct channel vulnerabilities. a cascade of k − 1 two-input selection elements. At each B. Write Request Static Profiling stage i, the selection element receives Ii and the previous stage’s output Oi−1, producing output Oi, thereby ensuring We first construct the WRG to model the arbitration and that higher-priority inputs are selected first. The selection logic priority relationships of write entities and identify potential is defined as follows: write port contention. • The first stage output is O1 = I1. 1) Write Request Graph Construction: Given a CPU RTL • For stage i (2 ≤ i ≤ k), the output is: design, PORTRUSH abstracts the WRG from its RTL code. In (I the WRG, each node represents a hardware element involved Oi = Oⁱ, if Ii = True (1) in the generation or transmission of write requests, such i−1, otherwise as functional modules (e.g., ALU), selection elements (e.g., After this transformation, the path of a write request multiplexers, arbiters), and storage elements (e.g., registers, from a write entity to the write port can be represented as: caches, and memory). Each edge denotes a possible data or W P =< (e, s′′1 ), (s′′1 , s′′2 ), . . . , (s′′t−1, s′′t ), (s′′t , se) >, where e control dependency between these elements, indicating how is the write entity, se is the storage element, and each s′′i a write request traverses from its source to its destination. denotes a two-input selection element. The union of all such Formally, we define the WRG as follows: nodes and edges forms the WRG, as illustrated in Figure 4. Definition 1 Given the RTL of DUT D, the WRG is 2) Priority Calculation: In the WRG, as outlined in For- defined as Gw(D) = (V, E), where V is the set of elements mula 1, a write entity attains higher priority if its write request in D, including write entities, selection elements, and storage is arbitrated by a selection element closer to the write port. elements. E is the set of directed edges (vi, vj ), where each Therefore, we first assign priorities to all selection elements edge indicates that a write request can propagate from vi in the WRG based on their shortest path distances to the write
5
Algorithm 1: Monitoring write port contention
1 Input: WRG of the DU T
[CONST] Output: Potential Write Port Contention Instances
[CONST] 1 M ← Prioritize_Modules(DU T )
[CONST] 2 foreach D ∈ M do
2 3 seqD, map1 ← Collect_Signals(D)
4 4 E ← Prioritize_Entities(D)
[CONST] 5
foreach Di ∈ U do
3 6 U ← Get_SubModules(D), seqD′ = seqD
[CONST] 7 seqi′ ← Collect_SubSequences (Di)
[CONST] 8 seqD′ , map2 ← Concatenate(seqD′ , seqi′)
Write Entities: 1 2 3 4 9 foreach ei ∈ E do
10 T seqi ← Construct_Target_Seq(map1, map2)
Selection Element: Storage Element: 11 Update((ei, T seqi))
Fig. 4: An illustration of the Write Request Graph 12 seqt ← seqDₜ // Dt is the top-level module
13 foreach D ∈ M do
14 seqD ← Extract_SubSequence(seqt), WD ← ∅
port, and then use these priorities to determine the priorities 15 foreach ei ∈ E do
16 if Match_Target_Values(T seqi, seqD) then
of the write entities. 17 WD ← WD ∪ ei // Record write request
By treating each edge traversal as a unit distance, the 18 seqD ← seqD \ Si // Remove bits
priority of a selection element s is defined as: 19 if |WD| > Nport then
20 Identify_Contention (WD)
priority(s) = maxD − d(s, se) (2)
Where d(s, se) is the shortest path length from the selection element s to the storage element se, and maxD is the maximum such distance among all selection elements. Thus, elements across RTL modules and determine whether the selection elements closer to the write port are assigned higher number of write requests simultaneously issued by write priorities. entities exceeds the number of write ports of the target storage Subsequently, the priority of a write entity e is the average element. The main challenge lies in efficiently collecting and priority of all selection elements along its write path: integrating signals from nested modules into the top-level P priority(si) module and accurately identifying write request behaviors priority(e) = sⁱ∈S |S| (3) from the aggregated signal sequence. PORTRUSH addresses these challenges in three steps: 1) Statically identify the Where S denotes the set of all selection elements along e’s expected signal values of all selection elements along each write path, and |S| denotes the number of selection elements in write entity’s write path when its request is accepted by S. This approach ensures that write entities traversing higher- the write port. 2) Collect and hierarchically aggregate these priority selection elements are assigned higher priorities. signals from all relevant selection elements into the top-level 3) Identification of Potential Write Port Contention: For a RTL module. 3) Design a Signal Decoder to interpret the given storage element se, if the number of write entities Ne aggregated signal sequence, thereby identifying write request simultaneously issuing write requests to the storage element behaviors and monitoring write port contention. The complete exceeds the available number of write ports Nport, it indicates detection algorithm is presented in Algorithm 1. the presence of potential write port contention instances. The 1) Static Analysis for Instrumentation: Given the WRG of number of such potential contention instances is calculated as: the DUT, PORTRUSH first statically prioritizes RTL modules X according to their hierarchical dependencies, reflecting the C N um(se) = Ne Nke (4) layered structure typical in RISC-V CPUs, where modules k=Nport+1 are instantiated within one another (Line 1). This ensures that lower-level modules are processed before their parent modules. Where C N um(se) denotes the total number of potential For each RTL module D in the prioritized list M, write port contention instances that may occur at se. According PORTRUSH identifies all relevant selection elements in the to Formula 4, when the number of entities attempting to issue WRG and their associated signals. Specifically, it determines write requests exceeds the number of available write ports, the the necessary signal conditions, referred to as target values, number of potential contention instances is determined by the that must be satisfied for each write entity to issue a valid combinations of these write entities. write request. This results in a signal sequence seqD for each C. Monitoring Write Port Contention module and a mapping map1 that associates each write entity Given the WRG, PORTRUSH employs a Hierarchical ei with its dependent selection signals and their required values Aggregation and Decoding method to monitor write port (Line 3): contention.The key idea is to monitor the signals of selection map1 = (ei, smi)|ei ∈ E, smi = (sj, vj)|sj ∈ Si, vj ∈ Vi (5)
6
Where E is the set of write entities in module D, Si is (Lines 17-18). This ensures that signal bits already claimed by the set of selection elements along the write path of ei, and higher-priority entities are not incorrectly attributed to others, Vi is the set of target values for these signals. This mapping reflecting the arbitration mechanism in RTL designs. enables precise identification of the conditions under which (3) Contention monitoring. The decoder records each write write requests are triggered, forming the basis for subsequent request. If the number of write entities issuing write requests decoding and contention detection. to the same storage element exceeds the number of available Subsequently, PORTRUSH enumerates and prioritizes the write ports in the same cycle, write port contention is triggered write entities in D according to their write priorities, en- (Lines 19-20). suring that entity-specific triggering conditions are accurately Steps (1)—(3) are repeated for all modules, ensuring that captured (Line 4). The set of all sub-modules instantiated all write request behaviors and potential contentions are accu- within D is denoted as U , and the local signal sequence rately identified. seqD is initialized for hierarchical aggregation (Line 5). Signal sequences are aggregated in a bottom-up manner: for each D. Hardware Fuzzing for Triggering Write Port Contention sub-module Di in U , its signal sequence seqi′ is concatenated We propose an efficient hardware fuzzing framework for with seqD′ to form the new aggregated sequence (Lines 6-8). triggering write port contention, driven by a PSO optimizer During each concatenation, a global offset mapping map2 is and proceeding in two phases. We first formalize seed gen- maintained, recording the position of each monitored signal eration and PSO optimization. Then, we optimize mutation within seqD′ . The offset for each signal is computed as: strategies by tuning mutation parameters to improve register X coverage and write request behavior coverage (Phase 1). of f seti = i−1 |seqₖ| + i − 1 (6) Finally, we minimize and reorder instruction sequences to k=1 trigger write port contention efficiently (Phase 2). map₂ = {(si, of f seti)| si ∈ S, of f seti ∈ N, 1 ≤ i ≤ n} (7) tion:1) Formalization of Seed Generation and PSO Optimiza- Let X denote the instruction space, the instruction set Where of f seti is the offset of element i in seqD′ , seqk is is I = {ik | k ∈ [1, Nop]}, where each instruction ik is the signal sequence of the k-th sub-instance, and S is the set defined by a tuple (opk, Dk, wk), representing the opcode, of elements. operand domain, and weight, respectively. The probability of Upon completion of hierarchical aggregation, for each write generating opcode opk is: entity ei in E , PORTRUSH constructs a global target signal P (op = opk) = P wk mapping T seqi that associates each relevant selection signal Nop w (9) with its required value at the corresponding global offset m=1 m (Lines 9-11): Where Nop is the number of opcode types in the RISC-V T seqi = {(of f setj,vj) | (sj, vj) ∈ map1(ei), of f setj = map2(sj)} (8) architecture. The mutator is modeled as a stochastic process M : Θ → X , with parameter space Θ = [lmin, lmax] × RNop , Where map1(ei) provides the monitored signal-value pairs where: + for ei, and map2(sj ) gives the global offset of sj in the • Ninst ∈ [lmin, lmax] is the instruction sequence length, concatenated sequence. T seqi thus specifies the target value uniformly sampled from the interval [lmin, lmax]. assignment for each relevant signal in ei. • θ = [w1, . . . , wN ] ∈ RNᵒᵖ is the opcode weight vector, seqAfter all modules are processed, the aggregated sequencet controlling P (opᵒᵖ= opk).+S for the top-level module Dt is constructed, representing • The output space is X = lmax I n, representing the set the unified runtime state of all monitored signals (Line 12). n=l of all instruction sequences with length in 2) Decoding Aggregated Sequence and Monitoring Write Based on this formalization, P min [lmin, lmax]. ORTRUSH samples opcode Port Contention: With the aggregated signal sequence, sequences OP = [op1, op2, . . . , opn] according to θ, and ran- PORTRUSH designs a Signal Decoder to identify write request domly generates operands datak within each Dk. To emulate behaviors and monitor write port contention as follows: hardware timing, interrupts δt ∼ N (μt, σt2) are randomly (1) Signal subsequence extraction. For each module D, the inserted between cycles. decoder uses map2 to extract the relevant signal subsequence, Mutation optimization with PSO. While the PSO opti- ensuring accurate tracking of signal paths for all write entities mizer adopts phase-specific strategies for distinct mutation (Line 14). operators, its fundamental objective is to guide mutation (2) Decoding and comparison. Write entities are processed strategies toward global optima—specifically, configurations in priority order (Line 15). For each entity ei, the decoder that maximize the triggering and exploitation of write port retrieves T seqi and compares the target values against the contention. corresponding bits in seqD (Line 16). If all values match, ei We choose PSO for its superior search capability in high- is identified as issuing a write request in the current cycle. dimensional continuous parameter spaces, which aligns with Moreover, once a write entity is matched, the associated signal our need to simultaneously optimize multiple mutation param- bits (e.g., si at of f seti in map2) are excluded from further eters (e.g., opcode weights, sequence lengths, and interrupt comparisons for the remaining lower-priority write entities timings). PSO efficiently converges toward global optima
7
through collaborative exploration and exploitation by a particle Algorithm 2: Optimizing Fuzzing Mutation with PSO
swarm. Each particle represents a candidate configuration and Input: Number of particles K, maximum iterations T , inertia
updates its search trajectory by tracking personal best and coefficient ω
global best positions. This mechanism enables PSO to balance Output: Optimal solution x∗
exploration (discovering diverse write request patterns) and 1 Initialize particle swarm pi with random parameters 2 Set iteration counter t ← 0 exploitation (reinforcing effective configurations) in Phase 1, 3 while t < T do while fine-tuning sequence minimization parameters in Phase 4 foreach particle pi do 2. Moreover, PSO’s stochasticity and adaptivity make it robust 5 Generate seeds Xi = Mutator(pi) for simulation to noise, which is critical for non-deterministic behavior in 6 Calculate reward R(xi) 7 if R(xi) > R(bi) then hardware fuzzing. In contrast to gradient-based methods or 8 Update particle’s personal best position bi ← xi MAB models [40], [41] commonly used in fuzzing, PSO does 9 Identify global best position g = arg maxi R(bi) not require differentiability of the objective function, making 10 foreach particle pi do it suitable for our coverage-based discrete feedback metrics. 11 Update velocity: vi ← ωvi + c1r1(bi − xi) + c2r2(g − xi) As detailed in Algorithm 2, a swarm of K particles is 12 Update position: xi ← xi + vi initialized, with each particle pi = (xi, vi) encoding a can- 13 Increment iteration counter t ← t + 1 didate mutation strategy xi and its corresponding velocity 14 return global best particle x∗ = g vi. Here, xi ∈ Rd represents the particle’s position in the parameter space, where d is the dimensionality of the mutation strategy (e.g., opcode weights θ and sequence length bounds). Where α, β, and γ are weights for register coverage, The velocity vi ∈ Rd determines the direction and magni- novelty of write request behaviors, and Gini penalty of write tude of parameter updates in subsequent iterations. Particle request behaviors, respectively. To simplify computation, we initialization is randomized to ensure sufficient diversity in set the values of α, β, and γ according to different DUT to the search space (Line 1). During each iteration, the mutator normalize their corresponding three terms, ensuring all values utilizes the parameters of each particle to generate a batch of fall within [0, 1]. The coverage term |Snew| measures the seeds Xi for RTL simulation (Line 5). To enhance optimiza- |Stotal| proportion of new register coverage relative to total register tion efficacy, distinct reward functions are designed for each coverage, reflecting the effectiveness of exploring new areas. fuzzing phase. Following simulation, PORTRUSH evaluates The novelty term rewards the coverage of previously unseen the reward associated with each particle (Line 6). Particles write request behaviors (i.e., write request behavior coverage), update their personal bests when improvements are observed, with the logarithmic function scaling the reward as more novel and the global optimum is concurrently tracked (Lines 7–9). behaviors are discovered. In this context, E = {e1, . . . , em} Subsequently, standard PSO update equations are applied, denotes the set of all write entities, and H is the subset that enabling adaptive adjustment of both positions and velocities has already generated write requests. The indicator function is in relation to individual and global bests (Lines 10–12). The defined as: ( settings of parameters in Line 11 follow established PSO I[e /∈H] = 0 if e is in H (11) practice to balance exploration and exploitation: population 1 otherwise size population size K ∈ [30, 50], iterations T ∈ [100, 200], inertia weight ω ∈ [0.4, 0.9] (gradually decreasing), accel- The Gini penalty term promotes balanced exploration eration coefficients c1, c2 ∈ [1.5, 2.0], and random factors among all write entities by discouraging uneven distribution r1, r2 ∼ U (0, 1). This iterative process proceeds for a pre- of write requests. Given this encoding and reward function, determined number of rounds, progressively refining mutation the PSO optimizer iteratively updates ⟨Ninst,⃗ θ, μt, σt⟩ to parameters to maximize both the coverage and exploitability maximize both coverage metrics throughout Phase 1. of write port contention events as potential side-channel attack 3) Phase 2: In Phase 2, seeds from the exploitation pool vectors. are first minimized to retain only instructions essential for triggering the observed write request behaviors. Subsequently, 2) Phase 1: The goal of PORTRUSH in Phase 1 is to the instructions within each minimized seed are reordered optimize the instruction sequence length, opcode types, and to maximize the likelihood that write requests from distinct opcode selection probabilities to maximize the register cover- entities coincide, thereby triggering write port contention. age and write request behavior coverage. Therefore, we use Seed minimization is performed via an iterative binary xi = ⟨Ninst,⃗ θ, μt, σt⟩ to encode the mutator parameters and search process. Starting from the original instruction sequence timing variations, while vi is the rate and direction of change IN , the sequence is recursively divided into two halves, for each parameter. The reward function in Phase 1 is designed I[0, N2 −1] and I[ N , N−1], and each half is simulated to verify based on coverage feedback collected during simulation and whether the targeted write request behaviors are preserved.² used to compute a reward for each particle (Line 6): If either half maintains the required coverage, minimization E continues recursively on that half. Otherwise, the current X X R(xi) = α |Snew| +β log 1 + X I −γ 1 E |e − e | (10) [e /∈H] 2E2 |Stotal{z |} e∈E e¯ i=1 j=1 i j sequence is identified as minimal with respect to the desired | {z } Coverage Novelty | Gini penalty{z } behaviors. All minimal sequences are subsequently grouped by
8
insert or replace low-priority insert or replace high-priority as measurable timing differences or microarchitectural state
write-eliciting instructions write-eliciting instructions changes, forming the basis of the side-channel attack.
High-latency Load secret and Secret-dependent To automate the generation of such attack patterns, we use
instructions extract secret bit instructions the PSO optimizer to jointly determine (i) how many high-
and low-priority instructions to insert or replace, (ii) their exact
data-dependent on Transient Secret-dependent positions within the instruction sequence, and (iii) whether the
Branch Branch resulting sequence successfully exposes a write port contention
Transient side-channel attack. Each candidate sequence encodes specific
Window
Fig. 5: Instruction sequence construction to validate write port insertion and replacement operations and is evaluated using the
contention vulnerabilities in the side-channel attack following three criteria.
Transient execution verification. We combine SpecDoc-
write entity, ensuring that each group targets the same storage tor [23] to monitor whether transient execution is successfully
element. triggered. Specifically, we leverage lightweight logic added to
Upon obtaining minimal instruction sequences, those within the CPU’s Reorder Buffer (RoB) to detect rollback events. the same group are concatenated, and their register, memory, Each rollback event is logged with relevant information, and address usage is optimized to minimize dependencies that including the cause of rollback, the opcode of the triggering could prevent simultaneous write requests. The concatenated instruction, the program counters for both the transient and instruction sequence is then subjected to a PSO-based per- correct paths, and the duration of the transient window. This mutation search, where each particle encodes a permutation mechanism enables us to accurately monitor whether and when xi = [k0, k1, k2, k3, . . . , kM−1], with kj denoting the position transient windows are opened during testing. of the j −th instruction in the concatenated sequence of length Write port contention monitoring. To determine whether M . The reward function is defined as: the generated instruction sequence triggers write port R(xi) = − min cycle − cycle (12) contention between low- and high-priority instructions, e1,e2∈E, e1=e2 e1 e2 PORTRUSH dynamically collects signal sequences that reflect Where E is the set of write entities in the current sequence, write port requests from instructions of different priorities. and cyclee denotes the clock cycle at which entity e issues a By interpreting these signal sequences, PORTRUSH can iden- write request. This formulation promotes instruction orderings tify cycles in which both high- and low-priority instructions that minimize the interval between write requests from differ- issue write requests simultaneously, thereby confirming the ent entities, thereby enhancing the probability of triggering occurrence of write port contention and its potential as a write port contention. The PSO optimizer then efficiently microarchitectural side channel. explores the permutation space based on this encoding and Timing side-channel observation. To assess the presence reward function. and effectiveness of a side channel, we measure the execu- tion time of the victim function under different candidate E. Write Port Contention Side-channel Validation sequences and secret values. Specifically, we examine whether To validate write port contention side channels in realistic significant timing differences arise when low- or high-priority attack scenarios, we combine contention-triggering instruction instructions are inserted or replaced, and whether flipping sequences with transient execution attack patterns. Transient the secret value (e.g., from 1 to 0 or vice versa) leads to execution, such as that enabled by speculative out-of-order corresponding changes in execution time. If both conditions execution, creates a transient window. During this window, in- are satisfied, the observed timing variations indicate that structions are executed speculatively. Although their architec- a practical and exploitable side channel exists. All timing tural effects are eventually squashed, their microarchitectural differences are recorded to support reward calculation. side effects, such as resource contention, remain observable. Based on the above criteria, the PSO optimizer evaluates As shown in Figure 5, we leverage this property by care- each candidate using the following reward function: fully arranging the instruction sequence. Low-priority write- R(x eliciting instructions are placed within hard-to-resolve i) = Itransient(xi) + Icontention(xi) + ∆t(xi) (13) (e.g., high-latency) instructions immediately before a sub- Where Itransient(xi) is an indicator function that equals 1 sequent transient branch. Meanwhile, high-priority write- if transient execution is successfully triggered in candidate eliciting instructions are inserted into secret-dependent in- sequence xi, and 0 otherwise. Icontention(x structions inside the transient window (i.e., after the transient write port contention is induced, and ∆t(xⁱ) indicates whetheri) measures the and secret-dependent branches, in the speculative path). This timing difference observed in the victim function. Based placement ensures that when the CPU speculatively executes on Formula 13, instruction sequences that keep the transient the transient window, high-priority instructions contend for window open, trigger write port contention, and cause observ- write ports with the preceding low-priority instructions. This able timing differences in the victim function receive higher contention occurs even though the speculative results will rewards. The optimizer thus automatically and heuristically eventually be discarded. The induced contention manifests searches for the optimal number and placement of low- and
9
high-priority instructions, ultimately identifying instruction TABLE I: Potential write port contention statically identified sequences that expose exploitable side channels. Target Storage Element Nport Write Entity Cont-Inst V. IMPLEMENTATION BOOM BoomDataArray array 0 0 1 LSU, BoomMSHRFile 1 BOOM BoomDataArray array 1 0 1 LSU, BoomMSHRFile 1 Static Analysis. To construct the WRG, extract the priorities BOOM BoomDataArray array 2 0 1 LSU, BoomMSHRFile 1 of write entities, identify potential write port contention, and BOOM BoomDataArray array 3 0 1 LSU, BoomMSHRFile 1 perform instrumentation for real-time monitoring of write port BOOM BoomMSHRFile lb 1 BoomMSHR, BoomMSHR 1 1 BOOM L1MetadataArray tag array 1 BoomMSHRFile, BoomProbeUnit 2 contention, we implemented a custom pass in the FIRRTL [11] Port 0: MemAddrCalcUnit, FPUUnit 1 compiler. First, we use sbt [7] to compile the Chisel source BOOM RegisterFileSynthesizable 1 regfile 2 Port 1: CSRFile, ALUUnit, PipelinedMulUnit, 11 DivUnit code into an intermediate FIRRTL representation for static BOOM RegisterFileSynthesizable regfile 2 Port 0: ALUUnit, PipelinedMulUnit, DivUnit 4 analysis, and then further compile the FIRRTL representation Port 1: FPUUnit, FDivSqrtUnit 1 into Verilog files. The implementation consists of two parts: NutShell Backend ooo T 2 CSR, MOU, LSU, ALU 42 Multiplier, Divider, BRU (i) a module (800+ LoC in Scala) for RTL graph analysis, NutShell MDU 1 Divider, Multiplier 1 WRG construction, extraction of write entity priorities, and NutShell ROB prf 2 CSR, MOU, LSU, ALU 42 Multiplier, Divider, BRU identification of potential write port contention; and (ii) a CSRFile, FPUFMAPipe, FPUFMAPipe 1, module (200+ LoC in Scala) for instrumenting wires and Core FPU regfile 1 MulAddRecFNPipe, MulAddRecFNPipe 1, 57 DivSqrtRecFN small, DivSqrtRecFN small 1 registers to monitor signals of selection elements within the Core Rocket T 815 1 MulDiv, CSR, FPU, ALU 11 WRG. Hardware Fuzzing. We implemented a hardware fuzzing coverage, write request behavior coverage, and detected write framework to generate instruction sequences that trigger write port contention instances to comprehensively evaluate the port contention. The framework is implemented in Python effectiveness of our approach. (600+ LoC) and includes: (i) a Signal Decoder to interpret aggregated signal sequences; and (ii) a Diagnoser to detect B. Identifying and Triggering Write Port Contention (RQ1) write port contention; and (iii) a PSO Optimizer to improve Detecting write port contention in our evaluation consists of write request behavior coverage, trigger write port contention, two stages. First, PORTRUSH performs static analysis to iden- and combine contention-triggered instruction sequences with tify potential write port contention by pinpointing architec- transient execution attack patterns for vulnerability validation. tural scenarios where multiple instructions may simultaneously VI. EVALUATION attempt to access shared write ports. Then, PORTRUSH em- ploys hardware fuzzing to automatically generate instruction To evaluate PORTRUSH, we conducted extensive experi- sequences that trigger actual write port contention instances, ments to answer the following research questions: thereby validating the existence and impact of such contention • RQ1: Can PORTRUSH detect write port contention? in the target microarchitecture. • RQ2: How does PORTRUSH perform in terms of cover- 1) Static Identification of Potential Write Port Contention: age? In the static analysis phase, PORTRUSH identifies storage • RQ3: Can write port contention triggered by PORTRUSH elements along with their associated write ports and write cause real security vulnerabilities? entities. If the number of write entities exceeds the num- • RQ4: How can write port contention be exploited to ber of write ports for a given storage element, that ele- construct side-channel attacks? ment is flagged as potentially susceptible to write port con- A. Evaluation Setup tention. The results of this static analysis on Rocket Core, BOOM, and NutShell are presented in Table I. The first Benchmarks. Most commercial processors are protected column (Target) lists the evaluated CPUs, while the second intellectual property without publicly available source code. (Storage Element) specifies the relevant storage elements. Therefore, we selected three large and widely used open- For instance, BoomDataArray array 0 0 refers to a sub- source RISC-V CPUs: Rocket Core [5], BOOM [43], and array within the BoomDataArray module. The third column NutShell [15]. These RTL cores are popular in the research (Nport) indicates the number of write ports associated with community and have been used in state-of-the-art studies [13], each storage element, and the fourth column (Write En- [24], [39], [42]. Among them, BOOM and NutShell are tity) enumerates the functional modules capable of issuing more complex than Rocket Core, featuring advanced microar- write requests to that element. The fifth column (Cont-Inst) chitectural capabilities such as superscalar and out-of-order reports the number of distinct contention instances possi- execution. ble for each storage element’s write ports. For example, Evaluation environment. All experiments were conducted BOOM’s RegisterFileSynthesizable 1 regfile fea- using software-based simulation within a Docker container tures two write ports. Port0 is shared by MemAddrCalcUnit on a 64-bit Ubuntu system. The host machine was equipped and FPUUnit, resulting in only one contention instance. with 80 CPU cores (Intel Xeon(R) Gold 6133 @ 2.50GHz). In contrast, Port1 is shared by CSRFile, ALUUnit, For each RTL design, we performed five independent fuzzing PipelinedMulUnit, and DivUnit, allowing for 11 distinct runs. After each run, we collected and analyzed the register potential contention instances, arising from all possible pairs,
10
TABLE II: Write port contention triggered by fuzzing TABLE III: Comparison with DiFuzzRTL on register coverage
Target Storage Element Nport Write Entity Cont-Insts Targets PORTRUSH DiFuzzRTL p-value
BOOM BoomDataArray array 0 0 1 LSU, BoomMSHRFile 1 Rocket Core 86,385 (-6.27%) 92,169 1.02 ∗ 10−4
BOOM BoomDataArray array 1 0 1 LSU, BoomMSHRFile 1 BOOM 407,661 (-7.03%) 438,519 3.16 ∗ 10−4
BOOM BoomDataArray array 2 0 1 LSU, BoomMSHRFile 1 Average 494,046 (-6.90%) 530,668 2.09 ∗ 10−4
BOOM BoomDataArray array 3 0 1 LSU, BoomMSHRFile 1
BOOM BoomMSHRFile lb 1 BoomMSHR, BoomMSHR 1 1
BOOM L1MetadataArray tag array 1 BoomMSHRFile, BoomProbeUnit 2
Port 0: MemAddrCalcUnit, FPUUnit 1
BOOM RegisterFileSynthesizable 1 regfile 2 Port 1: CSRFile, ALUUnit, PipelinedMulUnit, 7 TABLE IV: Comparison with DiFuzzRTL on WPC coverage
DivUnit
BOOM RegisterFileSynthesizable regfile 2 Port 0: ALUUnit, PipelinedMulUnit, DivUnit 4 Targets Potential PORTRUSH Coverage DiFuzzRTL Coverage
Port 1: FPUUnit, FDivSqrtUnit 1 Cont. Inst. Triggered (%) Triggered (%)
NutShell Backend ooo T 2 CSR, MOU, LSU, ALU 7 BOOM 24 20 83.3 5 20.8
Multiplier, Divider, BRU
NutShell MDU 1 Divider, Multiplier 1 NutShell 85 15 17.6 1 1.2
NutShell ROB prf 2 CSR, MOU, LSU, ALU 7 Total 109 35 32.1 6 5.5
Multiplier, Divider BRU
triples, and quadruple combinations of write entities. The potential write port contention detected by PORTRUSH not correlated with coverage, making it a meaningful indicator only guides the subsequent hardware fuzzing process but also of the fuzzer’s ability to reach contention conditions. Second, assists hardware designers and researchers in localizing and PORTRUSH and DiFuzzRTL share methodological similarities, understanding the root causes of possible write port contention as both derive coverage from MUX signals for coverage analy- side-channel vulnerabilities. sis (DiFuzzRTL) or port contention monitoring (PORTRUSH). As shown in Table I, there are 13 storage elements across Comparing coverage with DiFuzzRTL thus demonstrates that BOOM, NutShell, and Rocket Core that are susceptible to PORTRUSH’s port contention monitoring mechanism, coupled write port contention, with a total of 177 distinct instances with the PSO optimizer, does not introduce significant per- of potential port contention identified. Each instance can be formance overhead that would reduce coverage. To assess triggered by carefully crafted instruction sequences, which PORTRUSH’s effectiveness in uncovering functional vulnera- may be exploited to construct side-channel attacks. bilities, such as deviations between DUT execution and RISC- 2) Triggering Write Port Contention through Fuzzing: V ISA specifications, we directly compared PORTRUSH and The results of write port contention triggered by fuzzing are DiFuzzRTL under identical register coverage conditions. As presented in Table II. As shown, a total of 11 storage elements DiFuzzRTL does not support software simulation for NutShell, across BOOM and NutShell exhibited write port contention, our evaluation focuses on Rocket Core and BOOM, as sum- with 35 distinct contention instances successfully triggered. marized in Table III. This number is noticeably lower than the total number of potential write port contention instances for two reasons. First, Across five repeated fuzzing trials, PORTRUSH’s aver- some potential write port contention instances require three age register coverage on Rocket Core was 6.27% lower or more write entities to simultaneously issue write requests. than DiFuzzRTL, and 7.03% lower on BOOM. On average, Although our hardware fuzzing approach leverages a PSO PORTRUSH exhibited only a 6.90% reduction in register optimizer to optimize instruction ordering, such complex sce- coverage across both targets, suggesting that the additional narios are difficult to trigger within the limited 24-hour testing instrumentation and PSO-based optimizations in our hardware window. Second, due to Rocket Core’s in-order, single-issue fuzzing approach do not significantly degrade the ability to architecture, the identified potential port contention instances explore the DUT’s design space. cannot be activated in practice. Nevertheless, since some To more accurately assess PORTRUSH’s performance in superscalar, out-of-order RISC-V CPUs may be developed uncovering write port contention side-channel vulnerabilities, based on Rocket Core, the potential write port contention we introduce the metric of write port contention coverage detected in Rocket Core could propagate to advanced SoC (WPC coverage), defined as the proportion of statically designs, thereby introducing side-channel security risks. identified potential write port contention instances that are C. Evaluation on Coverage (RQ2) dynamically triggered during fuzzing. As Table IV shows, PORTRUSH achieves a WPC coverage of 83.3% on BOOM Beyond detecting write port contention, PORTRUSH pre- and 17.6% on NutShell, with an overall coverage of 32.1%. serves comprehensive design space exploration capabilities by In contrast, DiFuzzRTL only achieves 20.8% and 1.2% on leveraging the register coverage metric from DiFuzzRTL. the two CPUs, respectively, with an overall coverage of 5.5%. We adopt this coverage metric for two reasons. First, it These results demonstrate that, while maintaining competitive captures PORTRUSH’s ability to cover a broad range of distinct register coverage, PORTRUSH is significantly more effective write paths. Triggering write port contention instances requires than DiFuzzRTL in exercising and exposing write port con- executing multiple such paths, and their number is directly tention side-channel vulnerabilities in modern CPUs.
11
D. Write Port Contention Side-channel Vulnerability (RQ3)
By automatically combining discovered write port con- BoomDataArray
tention with known transient execution attack patterns, we dis- array_0_0
covered three vulnerabilities that can be exploited to construct Index Data (64bit) ....
write port contention side-channel attacks. Among them, two Transient: 0 0xade
are new vulnerabilities, Birgus-variant and MSHRush, if (secret == probe) 1... miss la x27, miss_cacheline
while the third is the known Spectre-STC vulnerability. store_storm Port ... lw x26, 0(x27)
The two newly discovered vulnerabilities have been reported
and assigned CVE identifiers. Cache Miss Process
By leveraging these vulnerabilities, we constructed write store Arbiter
instructions
port contention side-channel attacks on both BOOM and
NutShell processors. The performance of the three attack store req refill req
vectors is presented in Table V, where the Error Rate LSU (1) MSHR (2)
denotes the accuracy of secret leakage, and the Leakage
Rate represents the speed at which secret bits are leaked Fig. 6: The illustration of MSHRush attack
by the attack sequences generated by PORTRUSH. As shown in Table V, all three attack variants exhibit error rates below 10% and achieve leakage rates exceeding 15 Kb/s. 1 attacker: An error rate below 10% enables PORTR to accurately 2 USH rdcycle x10 3 call victim infer the value of each secret bit using a majority voting 4 rdcycle x11 scheme over repeated experiments. Specifically, for each secret 5 sub x11, x11, x10 6 /* Use timing difference in x11 to infer secret bit / bit, we perform the value inference five times, record the 7 victim: number of times the bit is inferred as 0 or 1, and select the 8 la x27, miss_cacheline / Address misses in cache / 9 lwu x25, 0(x27) / Cache miss and MSHR allocation / value with the higher count as the final result. This majority 10 lwu x26, 0(x25) / Load wait for refill completion / voting approach, combined with a low per-trial error rate, 11 ... / More instructions dependent on x25 and x26 / 12 beqz x30, L1 / Branch depends on refill result / ensures that each secret bit can be accurately recovered, as 13 transient: the probability of incorrect inference across multiple trials is 14 la x21, secret 15 lbu x22, 0(x21) / Load secret byte / significantly reduced. These results demonstrate that write port 16 andi x22, x22, 0x1 / Extract secret bit / contention side-channel vulnerabilities can serve as a reliable 17 beqz x22, L1 / If secret bit = 0, skip store storm / 18 la x23, store_array attack vector when combined with transient execution attack 19 li x24, 64 patterns, enabling effective leakage of secret values. Such write 20 store_storm: 21 sw x0, 0(x23) / Store hits to saturate write port */ port contention side-channel attack vectors are different from 22 addi x24, x24, -1 traditional cache-based attacks. They exploit competition for 23 bnez x24, store_storm 24 L1: limited write ports in shared CPU structures rather than cache 25 ... occupancy or timing, allowing information leakage even in 26 ret processors with secure or partitioned caches. Listing 2: MSHRush in BOOM. E. Case Study of the MSHRush Attack (RQ4) Write port contention of BOOM in DCache. In In this section, we analyze the newly discovered write BOOM, the L1 data cache (BoomDataArray_array) port contention side-channel vulnerability MSHRush in detail, provides only a single write port, shared by both and further explain how the new attack variant exploits the the Load/Store Unit (LSU) and Miss Status Handling contention vulnerability to leak secret information. Analysis Register (MSHR). When LSU and MSHR simultaneously issue of Birgus-variant and Spectre-STC is also provided write requests, the LSU is given higher priority, resulting in de- in §A and §B of the Appendix. layed MSHR refills. An attacker can saturate the store pipeline MSHRush is a Spectre-type attack targeting RISC-V BOOM so that the LSU issues continuous write requests, monopolizing that is unique in exploiting write port contention at the L1 data the write port and prolonging MSHR miss recovery. cache (BoomDataArray_array) rather than the register Technical details of MSHRush. Similar to Spectre-type at- file. The code snippet is shown in Listing 2, and the attack tacks, MSHRush exploits transient execution to encode secret flow is illustrated in Figure 6. information into microarchitectural state, write port contention timing. The attack creates a measurable timing difference in TABLE V: The performance of the three attack variants the victim function’s execution that depends on secret data. The attack proceeds in four phases: Variant Error Rate Leakage Rate New variant? (i) Establishing the transient window (Lines 8–12). The Birgus-variant 8.7% 24Kb/s ✓ attacker first ensures a cache miss by having the victim load MSHRush 4.5% 15Kb/s ✓ data from a deliberately evicted cache line (Line 9). This cache Spectre-STC 4.8% 19Kb/s × miss triggers an MSHR allocation to refill the missing data from
12
memory. The attacker then chains subsequent load instruc-
tions (Lines 10–11) and a conditional branch beqz (Line 12) 100 92 D0 Curve
that depend on the missed data. Since these instructions cannot D1 Curve
D0
resolve until the slow memory access completes, they create a 80 D1
dependency chain. Meanwhile, the branch predictor has been 60
trained to mispredict this branch, causing the processor to 45
speculatively execute the instructions following the branch,
which forms the transient window where attack operations will 40 23
occur. 20 22
(ii) Secret-dependent transient behavior (Lines 13–19).
Inside the transient window, the attack loads the secret value 0 518 536 558
and extracts its least significant bit (Lines 14–16). Crucially, Execution Duration (clock)
the attack then takes different execution paths based on this Fig. 7: Distribution of victim function execution cycles for secret bit: If the secret bit is 1, the attack enters a tight loop secret value equals 0 (D0) and 1 (D1) in MSHRush (Lines 18–23) that repeatedly executes store instructions. This store storm saturates the LSU pipeline, causing it to continuously issue write requests to the write port. Since LSU of victim is 518 cycles. When the secret is 1, the execution has higher priority than MSHR, this creates sustained write port duration of victim can be either 536 or 558 cycles. Thus, contention that blocks the MSHR refill operation. If the secret the expected execution duration, calculated as the sum of bit is 0, the store storm is skipped entirely, leaving the each cycle value multiplied by its probability, is 518 cycles write port available. The MSHR can complete its refill operation for secret 0 and 540 cycles for secret 1—a difference of 22 without interference. cycles. This 22-cycle increase demonstrates that write port (iii) Microarchitectural state persistence. When the orig- contention—triggered when the secret bit is 1—significantly inal cache miss finally completes, the branch mispredic- delays the execution of victim. The substantial and consistent tion is detected and all speculatively executed instructions timing difference between the two secret values demonstrates are squashed. For instance, the architectural effects (register the effectiveness of our approach in inducing measurable writes, etc.) are discarded. However, the microarchitectural timing side channels via port contention. timing effects persist. The write port contention caused by the store storm has already delayed the MSHR refill. This delay VII. DISCUSSION is observable because it affects when the dependency chain Root causes of write port contention. We present (Lines 11–13) can finally resolve and the victim function PORTRUSH, a systematic hardware fuzzing framework for can complete. detecting and analyzing write port contention side-channel (iv) Timing-based secret extraction. The attacker measures vulnerabilities at the RTL in modern CPUs. PORTRUSH can the total execution time of the victim function. When the systematically identify potential write port contention, trig- secret bit is 1, the write port contention delays the MSHR refill, ger such contention by fuzzing, and validate the vulnera- resulting in longer execution time. When the secret bit is 0, the bility of write port contention in real side-channel attacks. refill completes faster, resulting in shorter execution time. By This highlights the framework’s effectiveness compared to repeatedly invoking the victim function and measuring these traditional manual analysis and hardware fuzzing methods. timing differences, the attacker can reliably infer the value of Through extensive evaluation, PORTRUSH uncovers not only each secret bit, effectively leaking the entire secret one bit at new attack variants but also provides deep insights into the ar- a time. chitectural factors that make write port contention exploitable. We evaluated the attack by setting the secret to different Specifically, our study identifies root causes of write port values (e.g., 0xdeadbeef) and repeatedly testing the leak- contention in modern out-of-order RISC-V CPUs. First, write age accuracy. Figure 7 shows the distribution of execution port contention often arises when the number of write entities cycles for secret values 1 and 0. The x-axis represents clock exceeds the number of available write ports, as many designs cycles, while the y-axis indicates the number of times the deliberately limit the number of ports to balance design victim function executed in each cycle during the side- complexity, power consumption, and performance. Second, channel attack. For example, when inferring a 32-bit secret multi-issue out-of-order execution increases the likelihood of (e.g., 0xdeadbeef) with 5 repetitions per bit, there are simultaneous write requests, making it feasible for attackers 160 total measurements. These execution times may be dis- to manipulate dependencies and induce contention. Third, the tributed across different clock cycles. The red line shows the widespread use of fixed-priority arbitration schemes, such distribution when the inferred secret bit is 0, the blue line as static priority arbiters, can be exploited to favor certain corresponds to when it is 1, and some overlap exists due write requests consistently. Finally, short-latency instructions to noise, such as microarchitectural optimizations and RTL can preempt longer-latency instructions by completing and simulation variability. issuing write requests within a single cycle, thereby amplifying We observe that when the secret is 0, the execution duration contention and side-channel risk.
13
Count
Challenges in mitigating write port contention. Mitigat- bounded model checking to identify timing side-channels ing write port contention side-channel vulnerabilities presents or transient execution bugs in RTL designs. Fuzzing-based several challenges. While architectural optimizations such as techniques, such as Osiris [37], SIGFuzz [33], and Whis- fair or round-robin arbitration can be introduced at critical perFuzz [13], generate instruction sequences to trigger and points to distribute access more evenly, these approaches are analyze timing anomalies, aiming to uncover security-relevant not without drawbacks. For instance, in the MSHR scenario of timing behaviors. While these methods have advanced the BOOM, fair arbitration assigns equal priority and bandwidth detection of generic timing side-channels and some transient to store and MSHR refill requests, which can cause frequent execution vulnerabilities, they often struggle to pinpoint root interference and negatively impact overall CPU performance. causes at the level of specific microarchitectural resources, Attackers may also exploit these mechanisms by flooding the such as write ports, and may require substantial manual system with MSHR refill requests, thereby disrupting normal effort for vulnerability analysis and mitigation. This highlights store operations and inferring secret values through timing the need for automated, resource-aware detection frameworks analysis. Furthermore, increasing the number of write ports, capable of fine-grained vulnerability analysis. while potentially reducing contention, introduces additional Port Contention Side-Channels and Speculative Exe- design complexity, area, and power consumption. Thus, CPU cution Attacks. Recent studies have demonstrated that port designers must carefully balance performance, complexity, and contention—arising from competition for shared execution security when considering such mitigation strategies. resources—can serve as a powerful side channel in speculative Optimal architectural defenses. Effective mitigation re- and transient execution attacks. SMoTherSpectre [12] ex- quires a combination of targeted architectural enhancements. ploits execution port contention in simultaneous multithread- First, scaling the number of write ports to match the level ing (SMT) processors by flooding specific execution ports to of concurrent demand can minimize contention windows and infer secret-dependent instruction types, while PortSmash [2] structural hazards, reducing the risk of side-channel exploita- demonstrates cross-core port contention attacks on Intel’s tion. Second, prioritizing long-latency instructions during arbi- Skylake and Kaby Lake architectures by monitoring timing tration helps prevent critical operations from being persistently variations when concurrent threads compete for execution delayed by short-latency requests, thereby limiting observable ports. Both attacks operate at the instruction execution level, timing variations. Third, implementing advanced arbitration focusing on exploiting contention in functional execution mechanisms, such as round-robin or resource-aware policies, ports. In contrast, PORTRUSH targets write port contention—a at contention-prone points can further distribute access eq- distinct microarchitectural bottleneck that occurs when mul- uitably and prevent privilege escalation attacks. Collectively, tiple instructions or functional modules simultaneously at- these measures address both performance and security, making tempt to write results to shared storage elements such as them robust solutions for mitigating write port contention side- register files or cache arrays. While SMoTherSpectre and channel vulnerabilities in modern CPU microarchitectures. PortSmash rely on software-level profiling and manual attack VIII. RELATED WORK construction to detect and exploit execution port contention, PORTRUSH provides an automated, RTL-level approach that Hardware Fuzzing. Prior work in hardware fuzzing, identifies potential write port contention through static analysis such as RFUZZ [28], DifuzzRTL [24], MorFuzz [39], of hardware designs and automatically generates instruction RISCVuzz [35] and TheHuzz [26], has established coverage- sequences to trigger and validate these vulnerabilities during guided and differential fuzzing as effective techniques for the hardware design phase. exposing functional bugs and undocumented instructions at the register-transfer level (RTL) of CPUs. These frameworks IX. CONCLUSION utilize various strategies, including cycle-level input gener- CPU vulnerabilities continue to present significant security ation and automated test harnesses, to maximize hardware challenges in modern architectures, with write port contention coverage and identify behavioral discrepancies between the remaining an underexplored threat. In this paper, we intro- DUT and golden reference models. However, these approaches duced PORTRUSH, the hardware fuzzing framework designed are primarily oriented toward functional validation and do for the detection and validation of write port contention not provide targeted mechanisms to systematically detect or side-channel vulnerabilities at the RTL. By abstracting the analyze microarchitectural security vulnerabilities, such as Write Request Graph, employing a hierarchical aggregation write port contention. As a result, there remains a critical need and decoding method, and leveraging a contention-guided for specialized fuzzing frameworks that can uncover security- fuzzing approach powered by Particle Swarm Optimization, sensitive contention vulnerabilities at the RTL. PORTRUSH enables efficient detection and triggering of write Side-Channel and Transient Execution Vulnerability port contention. Our evaluation on three RISC-V CPUs, Detection. A substantial body of research has focused on BOOM, NutShell, and Rocket Core, demonstrates the effec- detecting microarchitectural side-channels and transient exe- tiveness of PORTRUSH in uncovering previously unknown vul- cution vulnerabilities, employing both formal verification and nerabilities. Notably, PORTRUSH discovered two novel attack fuzzing-based methodologies. Formal approaches, exemplified variants (Birgus-variant and MSHRush) and reproduced by UPEC [19] and Checkmate [36], use static analysis and the existing Spectre-STC attack on BOOM. These findings
14
highlight the security risks posed by write port contention and [14] Jo Van Bulck, Marina Minkin, Ofir Weisse, Daniel Genkin, Baris underscore the need for systematic hardware-level analysis to Kasikci, Frank Piessens, Mark Silberstein, Thomas F. Wenisch, Yuval mitigate such side-channel threats in future CPU designs. Yarom, and Raoul Strackx. Foreshadow: Extracting the keys to the intel sgx kingdom with transient out-of-order execution. In 27th USENIX ETHICAL CONSIDERATIONS Security Symposium (USENIX Security 18), Baltimore, MD, August 2019. USENIX Association. Our research on write port contention side-channel vulner- [15] RISC-V CPU Developed by OSCPU Team. Nutshell, 2025. https:// abilities might bring ethical concerns regarding experiment github.com/OSCPU/NutShell. environments and vulnerability disclosures. We have carefully [16] Chen Chen, Rahul Kande, Nathan Nguyen, Flemming Andersen, Aakash and proactively considered these research ethics throughout Tyagi, Ahmad-Reza Sadeghi, and Jeyavijayan Rajendran. HyPFuzz: Formal-Assisted processor fuzzing. In 32nd USENIX Security Sympo- this project. First, our research and experiments were con- sium (USENIX Security 23), pages 1361–1378, Anaheim, CA, August ducted in a local environment (e.g., servers) and did not 2023. USENIX Association. involve other persons or other live systems. Therefore, it would [17] D. Cyrluk, S. Rajan, N. Shankar, and M. K. Srivas. Effective theorem proving for hardware verification. In Ramayya Kumar and Thomas not have an impact on other parties or live services. Second, we Kropf, editors, Theorem Provers in Circuit Design, pages 203–222, attest that any newly discovered vulnerabilities were responsi- [18] Berlin, Heidelberg, 1995. Springer Berlin Heidelberg. bly disclosed to CVE to ensure proper mitigation. We did not Leonid Domnitser, Aamer Jaleel, Jason Loew, Nael Abu-Ghazaleh, and Dmitry Ponomarev. Non-monopolizable caches: Low-complexity publicly disclose the vulnerabilities to the broad audience to mitigation of cache side channel attacks. ACM Trans. Archit. Code avoid any potential harm or public exploitations. [19] Optim., 8(4), January 2012. Mohammad Rahmani Fadiheh, Johannes M¨uller, Raik Brinkmann, Sub- ACKNOWLEDGMENTS hasish Mitra, Dominik Stoffel, and Wolfgang Kunz. A formal approach The authors would like to thank the anonymous reviewers for detecting vulnerabilities to transient execution attacks in out-of-order processors. In 2020 57th ACM/IEEE Design Automation Conference for their insightful suggestions on our paper. This work is (DAC), pages 1–6, 2020. carried out with the support of the Hunan Provincial Key [20] Daniel Gruss, Moritz Lipp, Michael Schwarz, Richard Fellner, Laboratory of Intelligent and Parallel Analysis for Software Cl´ementine Maurice, and Stefan Mangard. Kaslr is dead: Long live kaslr. In Eric Bodden, Mathias Payer, and Elias Athanasopoulos, editors, Security, and is partially supported by the National Natural Engineering Secure Software and Systems, pages 161–176, Cham, 2017. Science Foundation China (62272472, 62306328, 62302050, [21] Springer International Publishing. 62372121, 62402509), the Science and Technology Innova- Daniel Gruss, Cl´ementine Maurice, Klaus Wagner, and Stefan Mangard. Flush+flush: A fast and stealthy cache attack. In Juan Caballero, Urko tion Program of Hunan Province (2024RC3136), the Inno- Zurutuza, and Ricardo J. Rodr´ıguez, editors, Detection of Intrusions and vative Research Group Project of National Natural Science Malware, and Vulnerability Assessment, pages 279–299, Cham, 2016. Foundation of China (62421002), the National University of [22] Springer International Publishing. Defense Technology Research Project (ZK23-14), the Nat- J. L. Hennessy and D. A. Patterson. Computer architecture: A quanti- tative approach. 2011. ural Science Foundation of Hunan Province (2021JJ40692, [23] Jaewon Hur, Suhwan Song, Sunwoo Kim, and Byoungyoung Lee. 2025JJ40053), and the Research Project of Key Laboratory Specdoctor: Differential fuzz testing to find transient execution vul- (WDZC20245250105). nerabilities. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, CCS’22, page 1473–1487, REFERENCES [24] New York, NY, USA, 2022. Association for Computing Machinery. Jaewon Hur, Suhwan Song, Dongup Kwon, Eunjin Baek, Jangwoo Kim, [1] Mor1kx, 2025. https://github.com/openrisc/mor1kx. and Byoungyoung Lee. Difuzzrtl: Differential fuzz testing to find cpu [2] Portsmash, 2025. https://github.com/bbbrumley/portsmash. bugs. In 2021 IEEE Symposium on Security and Privacy (SP), pages [3] Risc-v isa manual (privileged), 2025. https://riscv.org/specifications/ 1286–1303, 2021. privileged-isa/. [25] Saad Islam, Ahmad Moghimi, Ida Bruhns, Moritz Krebbel, Berk Gul- [4] Riscyoo: Risc-v out-of-order processors, 2025. https://github.com/csail- mezoglu, Thomas Eisenbarth, and Berk Sunar. Spoiler: Speculative load csg/riscy-OOO. hazards boost rowhammer and cache attacks. In 28th USENIX Security [5] Rocket core, 2025. https://github.com/chipsalliance/rocket-chip. Symposium (USENIX Security 19), SANTA CLARA, CA, August 2019. [6] Ryzenfallen, 2025. https://github.com/depletionmode/Ryzenfallen. USENIX Association. [7] scala-sbt, 2025. https://www.scala-sbt.org/. [26] Rahul Kande, Addison Crump, Garrett Persyn, Patrick Jauernig, Ahmad- [8] Side channel vulnerabilities: Microarchitectural data sampling and trans- Reza Sadeghi, Aakash Tyagi, and Jeyavijayan Rajendran. TheHuzz: actional asynchronous abort, 2025. https://www.intel.com/content/www/ Instruction fuzzing of processors using Golden-Reference models for us/en/architecture-and-technology/mds.html. finding Software-Exploitable vulnerabilities. In 31st USENIX Security [9] Synopsys vcs, 2025. https://www.synopsys.com/verification/simulation/ Symposium (USENIX Security 22), pages 3219–3236, Boston, MA, vcs.html. August 2022. USENIX Association. [10] Xiang shan, 2025. https://github.com/OpenXiangShan/XiangShan. [27] Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, [11] Chisel 3. A modern hardware design language, 2025. https://github. Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas com/freechipsproject/chisel3. Prescher, Michael Schwarz, and Yuval Yarom. Spectre attacks: Exploit- [12] Atri Bhattacharyya, Alexandra Sandulescu, Matthias Neugschwandtner, ing speculative execution. In 2019 IEEE Symposium on Security and Alessandro Sorniotti, Babak Falsafi, Mathias Payer, and Anil Kur- Privacy (SP), pages 1–19, 2019. mus. Smotherspectre: Exploiting speculative execution through port [28] Kevin Laeufer, Jack Koenig, Donggyu Kim, Jonathan Bachrach, and contention. In Proceedings of the 2019 ACM SIGSAC Conference on Koushik Sen. Rfuzz: Coverage-directed fuzz testing of rtl on fpgas. In Computer and Communications Security, CCS ’19, page 785–800, New 2018 IEEE/ACM International Conference on Computer-Aided Design York, NY, USA, 2019. Association for Computing Machinery. (ICCAD), page 1–8. IEEE Press, 2018. [13] Pallavi Borkar, Chen Chen, Mohamadreza Rostami, Nikhilesh Singh, [29] Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Rahul Kande, Ahmad-Reza Sadeghi, Chester Rebeiro, and Jeyavijayan Haas, Anders Fogh, Jann Horn, Stefan Mangard, Paul Kocher, Daniel Rajendran. WhisperFuzz: White-Box fuzzing for detecting and locating Genkin, Yuval Yarom, and Mike Hamburg. Meltdown: Reading kernel timing vulnerabilities in processors. In 33rd USENIX Security Sympo- memory from user space. In 27th USENIX Security Symposium (USENIX sium (USENIX Security 24), pages 5377–5394, Philadelphia, PA, August Security 18), pages 973–990, Baltimore, MD, August 2018. USENIX 2024. USENIX Association. Association.
15
[30] Sujit Kumar Muduli, Gourav Takhar, and Pramod Subramanyan. Hy- Functional Modules
perfuzzing for soc security validation. In 2020 IEEE/ACM International
Conference On Computer Aided Design (ICCAD), pages 1–9, 2020.
[31] Dag Arne Osvik, Adi Shamir, and Eran Tromer. Cache attacks and LSU (3) DIV (4) ALU (6) ……
countermeasures: The case of aes. In David Pointcheval, editor, Topics
in Cryptology – CT-RSA 2006, pages 1–20, Berlin, Heidelberg, 2006. req 1 req 2 req 3
Springer Berlin Heidelberg.
[32] Dag Arne Osvik, Adi Shamir, and Eran Tromer. Cache attacks and Issue
countermeasures: the case of aes. CT-RSA’06, page 1–20, Berlin, Same
[33] Heidelberg, 2006. Springer-Verlag. Arbiter Cycle
Chathura Rajapaksha, Leila Delshadtehrani, Manuel Egele, and Ajay
Joshi. Sigfuzz: A framework for discovering microarchitectural timing Port 1 Port 2
side channels. In 2023 Design, Automation and Test in Europe Confer-
ence and Exhibition (DATE), pages 1–6, 2023.
[34] W. Snyder. Verilator, 2025. https://www.veripool.org/wiki/verilator.
[35] Fabian Thomas, Lorenz Hetterich, Ruiyi Zhang, Daniel Weber, Lukas
Gerlach, and Michael Schwarz. Riscvuzz: Discovering architectural cpu
vulnerabilities via differential hardware fuzzing, 2024. ghostwriteat- Physical Register File
tack.com.
[36] Caroline Trippel, Daniel Lustig, and Margaret Martonosi. Checkmate: Reorder Buffer
Automated synthesis of hardware exploits and security litmus tests. In
2018 51st Annual IEEE/ACM International Symposium on Microarchi-
[37] tecture (MICRO), pages 947–960, 2018. Write requests > Write ports
Daniel Weber, Ahmad Ibrahim, Hamed Nemati, Michael Schwarz, and (req 1, req 2, req 3) (Port 1, Port 2)
Christian Rossow. Osiris: Automated discovery of microarchitectural
side channels. In 30th USENIX Security Symposium (USENIX Security
21), pages 1415–1432. USENIX Association, August 2021.
[38] Mario Werner, Thomas Unterluggauer, Lukas Giner, Michael Schwarz, Port Contention !
Daniel Gruss, and Stefan Mangard. Scattercache: thwarting cache attacks
via cache set randomization. In Proceedings of the 28th USENIX Fig. 8: The illustration of port contention in ROB prf
Conference on Security Symposium, SEC’19, page 675–692, USA, 2019.
USENIX Association.
[39] Jinyan Xu, Yiyuan Liu, Sirui He, Haoran Lin, Yajin Zhou, and Cong 1 attacker:
Wang. MorFuzz: Fuzzing processor via runtime instruction morphing 2
enhanced synchronizable co-simulation. In 32nd USENIX Security 3 rdcycle x10
Symposium (USENIX Security 23), pages 1307–1324, Anaheim, CA, call victim
4 rdcycle x11
August 2023. USENIX Association. 5 sub x11, x11, x10
[40] Tai Yue, Pengfei Wang, Yong Tang, Enze Wang, Bo Yu, Kai Lu, 6 /* Use timing difference in x11 to infer secret bit */
and Xu Zhou. EcoFuzz: Adaptive Energy-Saving greybox fuzzing as 7 victim:
a variant of the adversarial Multi-Armed bandit. In 29th USENIX 8 /*Prepare cache addresses and divisor before attack*/
Security Symposium (USENIX Security 20), pages 2307–2324. USENIX 9 li x14, 1 /* divisor for div_lsu_storm */
Association, August 2020. 10 la x25, hit-cacheline /*Pre-faulted, always cache-hit*/
[41] Gen Zhang, Pengfei Wang, Tai Yue, Xiangdong Kong, Shan Huang, 11 la x15, miss-cacheline /Pre-faulted, always Xu Zhou, and Kai Lu. Mobfuzz: Adaptive multi-objective optimization 12 ,→cache-miss/ in gray-box fuzzing. 2022. /* multiple alu instructions depend on x15 / 13 lwu x16, 0(x15) / Slow load from miss-cacheline / [42] Gen Zhang, Pengfei Wang, Tai Yue, Danjun Liu, Yubei Guo, and Kai Lu. 14 add x17, x16, x14 / Stall until load completes / Instiller: Toward efficient and realistic rtl fuzzing. IEEE Transactions on 15 sub x18, x17, x14 Computer-Aided Design of Integrated Circuits and Systems, 43(7):2177– 16 .... / More instructions dependent on x15 and x18 / 2190, 2024. 17 / Branch predictor misprediction setup / [43] J. Zhao, B. Korpan, and others. Sonicboom: The 3rd generation berkeley 18 beqz x18, L1 /Branch mispredicted as not taken/ out-of-order machine. 4th Workshop on Computer Architecture Research 19 transient: with RISC-V, 2020. 20 / Begin transient window / 21 la x19, secret / Load address of secret / 22 ld x20, 0(x19) / Load secret value / APPENDIX 23 div x21, x21, x20 /Secret-dependent division timing/ 24 div_lsu_storm: A. Birgus-variant in NutShell 25 / multiple div and lsu instructions within 1 cycle */ 26 lwu x24, 0(x25) We present Birgus-variant, a novel Spectre-type at- 27 div x24, x21, x14 28 lwu x24, 0(x25) tack discovered in NutShell that leverages previously unknown 29 ... write port contention to establish a new microarchitectural 30 L1: 31 ... side channel. Unlike prior port contention attacks [2], [12], 32 ret [23], Birgus-variant leverages contention at the Reorder Listing 3: Code snippet of Birgus-variant in Nutshell Buffer’s physical register file (ROB_prf) to leak secrets through timing. The code snippet is shown in Listing 3, and simultaneously issue write requests. Contention occurs when the attack flow is illustrated in Figure 9. more than two requests arrive in a single cycle, as shown Write port contention in ROB_prf of NutShell. Nut- in Figure 8. Arbitration delays lower-priority modules (e.g., Shell, a dual-issue out-of-order RISC-V core, provisions two ALU), introducing measurable timing variations. By exploiting write ports on ROB_prf to support concurrent write requests the variable latency of division instructions, an attacker can in- from functional modules (e.g., LSU, Divider, and ALU, etc.) duce and measure contention-dependent delays to infer secret However, as shown in Table I, up to seven modules may data.
16
Technical details of Birgus-variant. Similar to [Lines 1-3] Attacker (Time T0 in x11)
Spectre-type attacks, Birgus-variant exploits transient
execution attack patterns to encode secret information into
microarchitectural timing differences. The key insight is to [Lines 14-16] Multiple ALU instructions
[Lines4-6]
exploit the delay of lower-priority alu write requests caused
[Lines4-6]
by simultaneous higher-priority load and division instruc- [Line 18] Branch Mispredict depend on ALU Not taken
tions. By measuring execution time differences in the victim Victim Function
function, the attacker can infer secret data. The attack proceeds [Line 23] Secret
[Lines-dependent div
in four phases: 4-6]
(i) Establishing the transient window (Lines 9–18). The Secret =1, fast
attacker first prepares cache addresses and divisors (Lines Requests: [Lines 24-2[Lines 4
9] div_lsu_storm
-6]
9–11) to align div and load instructions, ensuring they can ALU Transient
complete in one cycle and issue write requests simultane- Execution
ously in the later div lsu storm. Multiple alu instructions
(Lines 14–16) are made data-dependent on a cache-miss load Requests:
instruction (Line 13), causing them to stall until the slow Port Contention LSU
memory access completes. The branch instruction beqz (Line and DIV
18) depends on these alu results. This branch has been trained
to mispredict, causing the processor to speculatively execute ALU instructions &
[Lines 4-6]
multiple instructions in the transient window (Lines 20–29). Victim delayed
(ii) Secret-dependent transient behavior (Lines 20–29). Longer Victim
Inside the transient window, the attack includes secret- execution time
dependent load and div operations (Lines 21–23). Crucially, Attacker infers secret
[Lines4-6]
the execution timing differs based on the secret bit. If the
secret bit is 0, the div instruction completes in one cycle, Fig. 9: The illustration of Birgus-variant
and the dependent div lsu storm instructions also finish
promptly. This avoids write port contention with the stalled
alu instructions. If the secret bit is 1, the div instruc- 120 D0 Curve 115
tion takes 16 cycles. Therefore, div and load instructions D1 Curve
in div lsu storm are delayed by 15 cycles and execute 100 D0
concurrently with the alu instruction waiting on the load 80 D1
dependency. This creates simultaneous write requests to the
two write ports of ROB_prf, causing write port contention 60
that further delays the lower-priority alu instructions. 45 20
(iii) Microarchitectural state persistence. When the origi- 40
nal cache miss completes, the branch misprediction is detected 20
and all speculatively executed instructions are squashed—their
architectural effects are discarded. However, the microarchitec- 0 56 76
tural timing effects persist. The write port contention caused Execution Duration (cycle)
when the secret bit is 1 has already delayed the alu instruc- Fig. 10: Distribution of victim function execution cycles for
tions. Since the beqz instruction branch resolution depends on secret value equals 0 (D0) and 1 (D1) in Birgus-variant
the completion of these alu instructions, the total execution
time of the victim function becomes secret-dependent and
remains observable. distribution when the inferred secret bit is 0, and the blue line
(iv) Timing-based secret extraction. The attacker measures corresponds to when it is 1.
the total execution time of the victim function to infer the
secret bit. We evaluated the attack by setting the secret to We observe that the execution time cluster is around 55
different values (e.g., 0xdeadbeef) and repeatedly testing cycles when the secret bit is 0, and around 75 cycles when the leakage accuracy. As shown in Figure 10, the distribution the bit is 1. This 20-cycle (36.6%) increase demonstrates of execution cycles differs significantly for secret values 1 that write port contention—triggered when the secret bit is and 0. The x-axis represents clock cycles, while the y-axis 1—significantly delays the execution of victim function. The indicates the number of times the victim function executed substantial and consistent timing gap between the two cases in each cycle during the side-channel attack. For example, demonstrates the effectiveness of our approach in inducing when inferring a 32-bit secret (e.g., 0xdeadbeef) with 5 measurable timing side channels via port contention, enabling repetitions per bit, there are 160 total measurements distributed accurate leakage of secret values despite microarchitectural across different clock cycle values. The red line shows the noise and simulation variability.
17
Count
B. Spectre-STC in BOOM Spectre-STC is a Spectre-type attack previously iden- tified in BOOM [13], [33]. This attack exploits a critical [Line 2] Victim & Time T0 microarchitectural feature of BOOM: the integer register file is equipped with a single write port shared among multiple [Line 10] Long-latency Division [DIV and ALU Storm execute concurrently] functional modules, including DIV, MUL, and ALU. When DIV, (OOO window) MUL, and ALU simultaneously issue write requests, a strict [Line 13] Mispredicted Branch arbitration policy prioritizes ALU and MUL units over the latency-sensitive DIV unit. The code snippet is shown in Listing 4, and the attack flow [Lines 16-18] Load Secret & Extract Secret Bit [ALU Storm creates write port contention] is illustrated in Figure 11, The attack proceeds as follows: i) (blocking DIV write) Insert the data-dependent and low-priority division instruction [Line 19] if (secret bit == 1) (Line 10). ii) Train the mispredicted branch to open the transient window (Line 13). iii) Load the secret and extract the secret bit (Lines 16-18), and set the secret-dependent [Lines 20-22] ALU Storm: multiple ALU instrs branch (Line 19). iv) Insert multiple alu instructions after the secret-dependent branch (alu storm), which will compete [Line 4] End & Time T1, ΔT = T1 - T0 with the division on the same write port. This contention (ΔT is larger if contention) only occurs for secret = 1, causing extra delay for the Fig. 11: The illustration of Spectre-STC attack division’s completion. After the branch resolves, speculative instructions are squashed, but the timing impact persists and can be measured by the attacker in register x11. Leveraging the write port contention side-channel vulner- ability found in Spectre-STC, PORTRUSH automatically generated the attack vector. We evaluated the attack by setting the secret to different values (e.g., 0xdeadbeef) and repeatedly testing the leakage accuracy. Our experimental results demon- strate that this attack achieves secret recovery with an error rate below 5% and a bit rate of 19 Kb/s, highlighting the effective- ness of combining transient execution with microarchitectural write port contention on modern out-of-order cores.
1 attacker: 2 rdcycle x10 3 call victim 4 rdcycle x11 5 sub x11, x11, x10 6 /* Use timing difference in x11 to infer secret bit / 7 victim: 8 ... 9 / low-priority div is data-dependent on beq branch / 10 div x18, x15, x14 11 ... 12 / Branch predictor misprediction setup / 13 beq x16, x18, L1 / Branch mispredicted as not taken / 14 transient: 15 / Begin transient window / 16 la x19, secret / Load address of secret / 17 ld x20, 0(x19) / Load secret value / 18 andi x21, x21, 0x1 / Extract secret bit / 19 beqz x21, L1 / If secret bit = 0, skip alu storm / 20 alu_storm: 21 / multiple alu instructions within 1 cycle */ 22 alu x24, x15, x14 23 ... 24 L1: 25 ... 26 ret
Listing 4: Spectre-STC in BOOM
18