Sonar: A Hardware Fuzzing Framework to Uncover Contention Side Channels in Processors

---

Review Form

Reviewer: The Guardian (Adversarial Skeptic)

Summary

The paper presents Sonar, a pre-silicon fuzzing framework that purports to systematically uncover contention-based side channels in processors. The core thesis is that multiplexers (MUXes) are the primary loci of resource contention, and by identifying these MUXes, one can define contention-critical states. The framework then uses these states, particularly the timing interval between requests (reqsIntvl), to guide testcase generation towards triggering contentions. The authors evaluate Sonar on two open-source RISC-V processors (BOOM and NutShell) and claim to have discovered 14 side channels, 11 of which are presented as new.

While the engineering of the framework appears functional for its defined scope, its fundamental premise is an oversimplification of microarchitectural contention. The methodology for guiding the fuzzer is naive, and the claims regarding the novelty and exploitability of the discovered vulnerabilities are not sufficiently substantiated.

Strengths

1. Automatable Heuristic for Contention Points: The core idea of leveraging MUX structures as a heuristic to identify potential contention points (Section 5.1, page 4) provides a scalable, automated starting point for analysis. The bottom-up tracing method is a logical way to group cascaded 2:1 MUXes into a single n:1 contention point.
2. Targeted Root-Cause Analysis: The dual-differential comparison method (Section 7, page 7), which correlates instruction commit cycle differences (CCD) with changes in contention-critical states, is a methodologically sound approach for narrowing down the source of a detected timing leak, reducing manual debugging effort.
3. Concrete Implementation: The framework is implemented and evaluated on two non-trivial out-of-order processor designs, demonstrating that the proposed instrumentation and analysis pipeline is functional.

Weaknesses

1. Oversimplified Contention Model: The central premise that MUXes are the definitive "hotspots" for all significant resource contention is fundamentally flawed. While MUXes are ubiquitous in signal selection, complex contention scenarios often arise from more intricate, stateful arbiters, queues with occupancy-dependent backpressure, and shared functional units whose contention logic is not fully captured by analyzing MUX input trees. This foundational assumption limits the scope of discoverable vulnerabilities to only those that manifest as simple signal selection conflicts, potentially missing more subtle and complex contention channels.

2. Naive Fuzzing Guidance Metric: The guidance metric, which exclusively seeks to minimize the request interval (reqsIntvl) (Section 6.2.1, page 6), is myopic. While forcing requests to be simultaneous (interval of zero) is a valid strategy for triggering simple volatile contentions, it fails to account for more complex scenarios. Many powerful side channels require precise, non-zero timing relationships (e.g., one request arriving exactly N cycles after another to exploit pipeline staging, buffer states, or arbiter fairness timers). The framework's singular focus on minimizing this interval is a greedy approach that likely prevents the discovery of such vulnerabilities and can easily get trapped in local optima where simple contentions mask the path to more complex ones.

3. Overstated Novelty of Findings: The claim of uncovering 11 "previously unknown" side channels (Abstract, page 1) is not supported by a rigorous analysis of the results. A close review of Table 3 (page 10) reveals that many of these "new" channels are simply instances of well-understood contention principles manifesting on the specific microarchitectures of BOOM and NutShell:

   • S1-S4 (TileLink Contention): This is a textbook case of bus/interconnect contention. Discovering that a long-running transaction can block a shorter one on a shared bus is not a novel vulnerability class.
   • S5 (MSHR Contention): This is a specific manifestation of MSHR pressure, a known side-channel vector. The paper itself notes its relation to Speculative Interference Attacks [11]. The "false sharing path blocking" appears to be a name for a specific trigger condition, not a new fundamental mechanism.
   • S11 & S12 (L1 DCache Contention): These are intra-thread variants of classic cache contention attacks (e.g., Prime+Probe, Flush+Reload). The novelty is limited to demonstrating they can be triggered without SMT, which is an interesting but incremental finding, not a new class of vulnerability.
   • The paper fails to demonstrate the discovery of a truly novel class of contention vulnerability.

4. Insufficient Evaluation of Exploitability: The exploitability analysis (Section 7.3, page 7 and Section 8.5, page 12) is superficial. Applying a generic Meltdown-style template demonstrates the existence of a transient execution window but provides no rigorous analysis of the signal-to-noise ratio, the difficulty of timing the attack under realistic system load, or the precise attacker capabilities required. The complete failure to construct a working PoC on NutShell (accuracy <2%) is a major red flag that is inadequately explained away by "earlier exception detection." This failure strongly suggests that the detected timing variations on NutShell are practically unexploitable and should not be classified as significant vulnerabilities without further evidence.

5. Limited Generalizability: The evaluation is confined to two academic, open-source RISC-V processors. The findings cannot be assumed to generalize to commercial-grade processors from vendors like Intel, AMD, or ARM, which feature far more complex and proprietary microarchitectures, interconnects, and prefetchers. Many of the uncovered issues appear to be artifacts of specific design choices in BOOM and NutShell rather than fundamental, universal principles.

Questions to Address In Rebuttal

1. Regarding the contention model: Can you provide a compelling argument or evidence that contention mechanisms not directly represented as MUX cascades (e.g., complex token-based arbiters, buffer occupancy management) are adequately covered by your approach? Please provide an example of a known side channel based on such a mechanism and explain how Sonar would detect it.

2. Regarding the guidance metric: How does the reqsIntvl minimization strategy avoid missing vulnerabilities that require a precise, non-zero timing interval between contending requests? Have you considered alternative guidance metrics that reward specific temporal patterns rather than just simultaneity?

3. Regarding novelty: Please justify the claim that channels S1-S4 and S11-S12 represent novel vulnerability classes, distinct from previously documented bus/interconnect and cache-based contention attacks, respectively. What is the fundamental new principle being demonstrated beyond its occurrence in a specific RISC-V core?

4. Regarding exploitability: Beyond citing "earlier exception detection," what specific microarchitectural investigation was performed to explain the <2% accuracy for the PoCs on NutShell? Does this result not suggest that the timing variations Sonar detects can be academic artifacts with no practical security impact? Why should these be considered exploitable vulnerabilities?

---

Review Form

Reviewer: The Synthesizer (Contextual Analyst)

Summary

This paper presents Sonar, a novel pre-silicon fuzzing framework designed to systematically uncover contention-based side channels in processor designs. The authors' core contribution is a microarchitecture-aware approach that departs from traditional random instruction fuzzing. Sonar is built on the key insight that resource contention often manifests at multiplexers (MUXes) within the circuit.

The framework operates in three stages:

1. It first uses a bottom-up tracing methodology starting from MUX outputs to automatically identify "contention points" and their associated states within the RTL design.
2. It then employs a state-guided fuzzing loop, using the timing interval between requests (reqsIntvl) at these contention points as a fitness metric to guide testcase mutation, progressively driving the design towards a state of contention.
3. Finally, it uses a "dual-differential comparison" method—comparing both instruction commit times and the microarchitectural contention states under different secret values—to accurately detect and pinpoint the root cause of the side channels.

Evaluated on the BOOM and NutShell open-source RISC-V cores, Sonar successfully identified 14 contention side channels, 11 of which are previously undocumented.

Strengths

The primary strength of this paper lies in its elegant and effective conceptual bridge between the architectural and microarchitectural domains for security verification.

1. A Powerful, Foundational Heuristic: The central idea to model resource contention as a problem of MUX arbitration (Section 5.1, page 4) is a significant contribution. It provides a concrete, automatable, and scalable way to find potential contention "hotspots" across a complex processor design without needing manual specifications. This moves the field beyond simply fuzzing instructions and hoping for the best, towards a more targeted and intelligent search. It's a foundational insight that could inform future work in hardware security verification.

2. Effective State-Guided Fuzzing: The paper successfully translates this microarchitectural insight into a practical feedback mechanism for fuzzing. Using the request interval (reqsIntvl) as a fitness function (Section 6.2.1, page 6) is a clever way to solve the notoriously difficult problem of triggering timing-sensitive events. It creates a gradient that the fuzzer can descend to force simultaneous requests, something that random mutation would struggle to achieve efficiently. This methodology represents a significant maturation of hardware fuzzing techniques for security.

3. Contextual Significance and Strong Results: This work is situated perfectly at the intersection of hardware verification and computer security. The need for pre-silicon detection of side channels is well-established, as post-silicon fixes are immensely costly. By finding 11 new, potentially exploitable channels in well-regarded open-source designs like BOOM (Table 3, page 10), the authors provide compelling evidence that their framework is not just a theoretical novelty but a practical and necessary tool. It effectively addresses a known gap left by both less-targeted fuzzers (like SpecDoctor) and less-scalable formal methods (like UPEC).

4. End-to-End Systematization: Sonar is presented not as a single trick, but as a complete, end-to-end framework. The combination of automated hotspot identification, guided triggering, and the dual-differential analysis for precise detection creates a systematic and repeatable process. This level of automation is crucial for integrating security analysis into the standard hardware design lifecycle.

Weaknesses

The weaknesses of the paper are primarily related to the boundaries of its core assumptions and its positioning relative to adjacent methodologies. These are opportunities for clarification and future exploration rather than fatal flaws.

1. Conceptual Limits of the MUX Model: The MUX-centric view is powerful for arbitrated resources (ports, buses, interconnects), but its applicability to other forms of contention is less clear. For example, the paper reports finding contention on a non-pipelined Multiply-Divide Unit (S13). While this is a valid contention channel, it stems from the unit's internal "busy" state rather than an input MUX selecting between competing requests. The paper would be strengthened by a discussion on the conceptual limits of the MUX model and how it generalizes (or doesn't) to other forms of resource occupancy.

2. Generalizability of the Implementation: The framework's implementation relies on analyzing FIRRTL, a high-level intermediate representation generated from Chisel (Section 8.2, page 8). While this is pragmatic for academic research using open-source cores, it raises questions about its applicability in industrial settings, which predominantly use Verilog/SystemVerilog and may not provide access to such a high-level IR. A discussion on the challenges and potential pathways for adapting the "bottom-up tracing" to standard Verilog RTL or even gate-level netlists would significantly broaden the perceived impact of this work.

3. Nuance in Comparison to Formal Methods: The paper positions itself against formal methods primarily on the basis of scalability. This is a fair and important point. However, the discussion could be more nuanced. Formal methods provide proofs of absence (within certain bounds), a powerful guarantee that fuzzing cannot offer. A brief exploration of the fundamental trade-offs would be valuable. Are there classes of contention channels Sonar might miss that a formal tool could theoretically find, and vice versa?

Questions to Address In Rebuttal

1. Could the authors elaborate on the conceptual boundaries of their MUX-based contention model? For instance, how does it capture contention for non-pipelined functional units (e.g., S9, S13 in Table 3) where the bottleneck isn't necessarily request arbitration at an input MUX, but rather the busy state of the unit itself? Is the framework implicitly monitoring this through other MUXes (e.g., on the writeback path), or does this suggest the need for a hybrid model?

2. The reliance on FIRRTL is pragmatic for the chosen evaluation targets. Can the authors comment on the feasibility of adapting the "bottom-up tracing" methodology to more standard, lower-level representations like Verilog RTL or even gate-level netlists, which would be crucial for industrial adoption?

3. Beyond scalability, could you provide more insight into the fundamental trade-offs between Sonar's dynamic approach and formal verification methods like UPEC? Are there specific types of contention channels (perhaps those requiring extremely complex state setup) that one is inherently better suited to find than the other?

Review Form

Reviewer: The Innovator (Novelty Specialist)

---

Summary

This paper presents Sonar, a pre-silicon fuzzing framework for detecting contention-based side channels in processor RTL designs. The authors propose a three-part methodology. First, they introduce a technique to systematically identify potential contention points by treating multiplexers (MUXes) as proxies for resource arbitration and using a bottom-up tracing algorithm. Second, they employ a guided fuzzing strategy where the feedback metric is the timing interval between competing requests (reqsIntvl) at these MUX-defined contention points, with the goal of minimizing this interval to trigger simultaneous contention. Third, they use a "dual-differential" analysis method to confirm the side channel, which compares both instruction commit-timing differences and the underlying microarchitectural contention states under different secret values.

The core novelty of this work rests on the combination of these three ideas: the systematic, structural identification of contention points via MUX analysis to guide a fuzzer, the use of a microarchitectural timing interval as a direct feedback loop for mutation, and the automated root-cause analysis that links observed timing effects to specific contention events. While individual components build on existing concepts (guided fuzzing, differential testing), their synthesis into a cohesive framework targeted specifically at contention side channels appears to be a novel contribution to the field of pre-silicon hardware security verification.

Strengths

From the perspective of novelty, the paper has several significant strengths:

• S1: A Novel Heuristic for Locating Contention. The central idea of using MUXes as a structural signature for contention points (Section 5.1, page 4) is a genuinely new and clever heuristic for the purpose of fuzzing. Prior fuzzing work (e.g., SpecDoctor, SIGFuzz) has relied on more abstract or effect-based monitoring (e.g., transient state coverage, commit timing). Sonar's approach is the first I am aware of to systematically parse the circuit structure itself (via FIRRTL) to derive targets for contention, which is a significant methodological advancement. The "bottom-up tracing" method to identify the full set of inputs to a cascaded MUX is a concrete, novel algorithm that enables this approach.

• S2: A Novel Feedback Mechanism for Triggering Contention. Guided fuzzing is not new, but the choice of feedback is critical and domain-specific. The authors' proposal to use the inter-request timing interval (reqsIntvl) as the fitness function for the fuzzer (Section 6.2.1, page 6) is a novel application tailored to the unique challenge of triggering timing-sensitive microarchitectural events. Driving mutations to explicitly minimize this value is a far more directed strategy than the random or coverage-guided approaches of prior work and represents a new technique in the hardware fuzzer's toolkit.

• S3: A Novel Method for Automated Root Cause Analysis. Standard differential testing can reveal the existence of a timing leak, but not necessarily its cause. Sonar’s "dual-differential comparison" method (Section 7, page 7) is a notable contribution. By simultaneously comparing the Commit Cycle Difference (CCD) to isolate the affected instruction and the contention state logs to identify the responsible MUX, the framework moves beyond mere detection to automated attribution. This linking of effect to cause is a qualitative improvement over prior art and represents a novel analysis workflow.

Weaknesses

The primary weaknesses relate to the framing of the novelty and the evaluation of its significance.

• W1: Overstated "First Mover" Claim. The abstract claims Sonar is the "first systematic and automated fuzzing framework designed to uncover contention side channels". This claim is too strong and potentially misleading. Frameworks like SpecDoctor [25] and SIGFuzz [26] are also fuzzing frameworks that can, and do, uncover contention side channels (e.g., port contention is a known Spectre-v4 variant). The true novelty of Sonar is not that it finds them, but how it finds them. The claim should be refined to state that it is the first framework to use structural analysis of arbitration logic (MUXes) to systematically guide a fuzzer towards triggering these contentions. The innovation is in the specific guidance mechanism, not in being the first tool in the category.

• W2: Insufficient Differentiation from Conceptually Adjacent Ideas. The concept of resource contention is fundamental to computer architecture. While using MUXes for fuzzing is new, the idea that arbiters are contention points is not. The paper would be stronger if it more clearly delineated why its automated MUX-based approach provides a significant advantage over a simpler, more manual approach where a designer might identify major arbiters (e.g., for execution ports, memory ports, bus interfaces) as monitoring targets. The novelty lies in the automation and scale, and this should be emphasized more.

• W3: Complexity vs. Benefit Analysis. The proposed methodology introduces significant complexity: a full-design RTL pass for MUX tracing and extensive instrumentation for dynamic reqsIntvl monitoring. The overheads are non-trivial, as shown in Table 2 (page 9). For the novelty to be truly significant, the benefit must clearly outweigh this cost. The comparison with SpecDoctor in Section 8.3.4 (page 9) shows Sonar triggers more contentions, which is a good result. However, this comparison doesn't fully assess the trade-off. Is it possible that a much simpler heuristic (e.g., monitoring a handful of key pipeline stall signals) could achieve 80% of the results with 10% of the complexity? A discussion on this trade-off would help solidify the significance of the proposed novel, but complex, approach.

Questions to Address In Rebuttal

1. Please refine your primary novelty claim. Given that prior fuzzers like SpecDoctor [25] can detect contention-based channels, can you clarify precisely what makes Sonar the "first" in its class? Is the novelty more accurately described as being the first structurally-guided fuzzer for this purpose?

2. The core of your guidance is the MUX-based heuristic. How robust is this heuristic? Are there common sources of resource contention in modern processors that are not implemented with straightforward MUX trees and would therefore be missed by Sonar? Conversely, does the automated tracing produce a large number of "contention points" at MUXes that are architecturally uninteresting or do not represent a meaningful shared resource, leading to wasted effort by the fuzzer?

3. Your reqsIntvl feedback mechanism is innovative but seems computationally intensive. For a complex contention point with N inputs, the fuzzer must track O(N^2) request pairs. How does the framework scale as the number of identified contention points and their input fan-in increases, especially in a large, complex SoC design beyond the evaluated BOOM/NutShell cores?