{"id":"0a4fac02-1340-472c-82c1-570f2cabe3d4","arxiv_id":"2504.20934","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":8.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"DejaVuzz combines dynamic memory swapping with differential taint tracking to trigger and detect transient execution vulnerabilities, discovering five new bugs with six CVEs.","lead":"DejaVuzz is a new fuzzer that finds transient execution bugs in processor designs before they are manufactured. It isolates training from attack code with swappable memory and compares two chip instances with different secrets to track information flow, reporting five new vulnerabilities with six CVEs.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 4.7x coverage claim over SpecDoctor is measured with a metric DejaVuzz defines and optimizes while SpecDoctor inputs are replayed under that metric, so the headline SOTA improvement may be inflated and needs an oracle- and wall-clock-controlled comparison.","rationale":"The CVE-backed bug discoveries are strong, concrete evidence that DejaVuzz works, so the central detection claim survives scrutiny. The most fragile part of the paper is the quantitative claim that DejaVuzz outperforms SpecDoctor by 4.7x in coverage with lower training overhead. That claim depends on a metric that DejaVuzz itself defines and optimizes, while SpecDoctor's generated test cases are replayed after the fact and measured with this unfamiliar metric. The comparison also uses number of iterations as the x-axis, ignoring per-iteration simulation cost, and the training-overhead table counts training instructions while excluding the re-simulations required by the training-reduction strategy. The diffIFT under-approximation identified by the reader is real but explicitly acknowledged in Section 7, and it affects completeness rather than the validity of the found bugs; it is not the most load-bearing issue for the headline comparative claim. The reader's rationale already includes the coverage-metric concern, so I partially agree with the reader, but I would elevate it above the diffIFT under-approximation as the primary reason for conditional acceptance. Because the paper still has real vulnerabilities, verified by maintainers and assigned CVEs, the appropriate verdict remains conditional rather than rejection; the requested clarifications and artifact pinning should be focused on making the SpecDoctor comparison apples-to-apples.","tokens_in":22525,"tokens_out":9538,"duration_ms":107327,"concrete_test":"Run both fuzzers on the same BOOM version under identical wall-clock budgets (e.g., 24 hours on 16 threads) and report three quantities: (i) DejaVuzz-style taint coverage points, (ii) the number of distinct SpecDoctor-style timing-difference states, and (iii) the number of confirmed leakages. If DejaVuzz's 4.7x taint-coverage advantage is not accompanied by a comparable advantage on (ii) and (iii), the headline coverage comparison is metric-biased. In addition, rerun the comparison with equal-length and equal-complexity secret-encoding blocks across both fuzzers to rule out mechanical taint-count inflation from longer instruction sequences.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central comparative claim that DejaVuzz \"achieves a 4.7x coverage improvement\" over SpecDoctor is not supported by a fair comparison. In Section 6.3, the paper states it \"replay[s] the phase 3 test cases generated by SpecDoctor in our environment\" and measures them with taint coverage (Section 4.2.2), a metric that SpecDoctor does not and cannot observe and that DejaVuzz uses as its mutation objective. A baseline that never sees the evaluation metric is structurally disadvantaged, so the ratio largely measures how well DejaVuzz matches its own objective rather than how much better it explores or finds bugs. The metric itself compounds this: each coverage point is a (module, per-cycle tainted-register count) tuple, so longer or more arithmetic-heavy secret-encoding blocks can mechanically increase coverage without exploring new microarchitectural behaviors. The paper itself notes that \"higher coverage does not guarantee more bugs,\" yet the 4.7x number is promoted in the abstract as evidence of outperforming the state of the art. This concern is distinct from, and more load-bearing than, the admitted diffIFT under-approximation: even if diffIFT were exact, the comparison methodology would remain questionable. It is load-bearing because the abstract and introduction present the 4.7x improvement as a primary result, and the direct bug-finding comparison is anecdotal (SpecDoctor found no vulnerabilities in the replayed evaluation), which makes the fairness of the baseline setup central to the claim. The 5 CVE-backed discoveries are credible independent evidence and are not undermined by this concern, but the quantitative SOTA comparison needs to be validated under a more neutral evaluation protocol.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes DejaVuzz, a pre-silicon fuzzer for transient execution vulnerabilities in RTL processors. It introduces two primitives: swapMem, which time-shares the address space so that training and transient instruction sequences can be scheduled without address conflicts, and diffIFT, which runs two DUT instances with different secrets and suppresses control taints unless the corresponding control signals differ between the instances. The primitives are used to trigger diverse transient windows, guide mutation through a taint-coverage matrix, and identify exploitable leaks via taint-liveness annotations. The evaluation on BOOM and XiangShan reports a 4.7x coverage improvement over SpecDoctor, lower training instruction overhead, and five previously unknown vulnerabilities with six assigned CVEs.","tokens_in":22841,"tokens_out":8676,"duration_ms":92095,"significance":"The strongest evidence is the discovery of five previously unknown transient execution bugs (B1-B5) with independently assigned CVEs on two nontrivial open-source RISC-V processors, with fixes for XiangShan confirmed by maintainers and source code/experiments publicly released. The swapMem and diffIFT ideas target genuine controllability and observability gaps in prior fuzzing work, and the taint-liveness oracle is a useful step toward reducing the false positives that plague earlier oracle designs. The main reservation is that the headline '4.7x coverage improvement' is measured with DejaVuzz's own taint-coverage metric over a replayed SpecDoctor corpus, so it does not constitute a fair end-to-end comparison and should not be presented as state-of-the-art superiority. The contribution is therefore significant despite the quantitative comparison requiring substantial rework.","major_comments":[{"comment":"The 4.7x coverage claim used in the abstract and introduction is not supported as a state-of-the-art comparison. The evaluation 'replays the phase 3 test cases generated by SpecDoctor' through the taint-coverage metric defined in §4.2.2; SpecDoctor never receives feedback from this metric, so it is structurally unable to optimize it, and the ratio largely measures how well DejaVuzz matches its own objective. Furthermore, the x-axis is iterations, not wall-clock time, while DejaVuzz runs two diffIFT-instrumented DUTs per iteration, so per-iteration cost is higher. The paper itself notes in §6.4 that 'higher coverage does not guarantee more bugs,' making this metric unsuitable as the sole evidence for outperforming SpecDoctor. I recommend supplementing or replacing this comparison with (a) wall-clock time to find known bugs under the same simulator and thread budget, and (b) an evaluation metric that is not the fuzzer's own mutation objective, or clearly qualifying the claim.","section":"§6.3, Fig. 7, §4.2.2"},{"comment":"The taint-coverage point is defined as a (module, per-cycle tainted-register-count) tuple. This definition mechanically rewards encoding blocks that taint more registers for more cycles, even if the same transient behaviors are exercised, and no experiment in §6.3 demonstrates that this metric correlates with vulnerability discovery. Because the same metric also guides mutation in Phase 2, the reported coverage improvement is partly circular. I would like to see a validation of the metric: for example, its precision and recall on a labeled corpus of known transient-execution bug triggers and non-bugs, and an ablation showing that mutations chosen by taint coverage lead to bug detection rather than only to higher raw taint counts.","section":"§4.2.2, §6.3"},{"comment":"The paper correctly states that diffIFT is an under-approximation because it compares only two concrete values. The proposed mitigation, flipping each bit of the secret, does not guarantee divergence of a secret-dependent control signal when the signal's value depends on multiple bits or on equality of derived values; in such cases control taints are suppressed and leaks that require a speculative control-flow change are missed. This is acknowledged in §3.3 but not quantified. Since taint coverage and mutation in Phase 2 depend on the resulting taint traces, the effect is not limited to oracle recall; it can also bias exploration. I request an experiment measuring the false-negative rate on known bug-triggering test cases with several secret pairs, and a discussion of whether the bit-flip secret generation is sufficient for the control-flow-dependent bugs B2-B5.","section":"§3.3, Table 1, Fig. 6"},{"comment":"The taint-liveness oracle is manual. Table 2 reports 212 and 592 lines of annotation for BOOM and XiangShan, and §7 acknowledges that DejaVuzz 'currently relies on manual taint liveness annotations.' The paper does not report the effort or expertise required to create these annotations, nor what happens when annotations are incomplete: an unannotated state register that gates an exploitable tainted sink will be silently filtered out. Because the oracle is central to false-positive reduction and to the bug reports, the reproducibility and generality claims are incomplete without a description of the annotation workflow, a validation that all relevant state registers are annotated for the two cores, and an assessment of sensitivity to annotation errors.","section":"§4.3.2, Table 2, §7"}],"minor_comments":[{"comment":"The training-overhead comparison would be easier to interpret if SpecDoctor's ETO were also reported; as it stands, Table 3 gives TO for SpecDoctor and both TO and ETO for DejaVuzz, so the 'lower training overhead' claim does not compare like with like in every row.","section":"§6.2, Table 3"},{"comment":"In the liveness evaluation of SpecDoctor, please clarify whether the 75 test cases come from a full SpecDoctor run or from the replayed corpus used in Figure 7; the current wording is ambiguous.","section":"§6.3"},{"comment":"The statement that DejaVuzz 'detects the first bug in an average of about 10 minutes' should be accompanied by the number of runs, the variance, and the exact hardware configuration; a single average over 16 threads is not a distribution.","section":"§6.4"},{"comment":"Step 4 of the attack (decoding the secret) is only mentioned in the figure caption; the text should explain how the proposed oracle observes this step, since the oracle is based on taint liveness rather than on decoding a side channel.","section":"§2.1, Figure 1"},{"comment":"The claim that DejaVuzz 'covers transient windows triggered by all instruction types' is broader than what is evaluated; please qualify the claim to the supported trigger types (sequential, control transfer, and architectural exceptions).","section":"§4.1.1"}],"recommendation":"major_revision","confidential_remarks":"The paper has external grounding through independently assigned CVEs and an open-source artifact, and the technical primitives are genuinely useful. The main risk is the SOTA comparison in the abstract, which rests on a self-referential coverage metric and a replayed baseline. I believe major revision is appropriate rather than rejection, since the discovered vulnerabilities are concrete and the primitives make a contribution even if the coverage claim is reframed as a qualitative or bug-centric result."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here’s my take. The two primitives—swapMem and diffIFT—are genuinely new, and the five CVE-backed bug discoveries on BOOM and XiangShan are enough to make this paper worth reading. But the headline \"4.7x coverage improvement\" over SpecDoctor is not supported by the comparison as run. I’d treat that number as suggestive, not solid.\n\nWhat’s good: swapMem’s insight that address space can be time-shared, so training and transient sequences don’t collide, is a real step beyond prior fuzzers. The training reduction strategy—removing one packet at a time to see if the window still triggers—is simple and effective; Table 3 shows misprediction-type windows down to ~3 effective instructions. diffIFT’s trick of running two DUTs with different secrets and propagating control taints only when the control signal differs is a clean way to attack control-flow over-tainting. It avoids the taint explosion that CellIFT hits on BOOM, with much lower compile-time overhead.\n\nThe five vulnerabilities are the strongest part. They have CVEs, so they’re externally validated. The analyses (Phantom-RSB, Phantom-BTB, MeltDown-Sampling, two Spectre-Rewind variants) are detailed and plausible. This is exactly what matters for pre-silicon testing.\n\nThe coverage evaluation is the load-bearing soft spot. The taint coverage metric is DejaVuzz’s own, used as its mutation objective, and SpecDoctor’s phase-3 test cases are replayed under that same metric. SpecDoctor never sees it, so it’s structurally disadvantaged. Worse, a coverage point is just a (module, per-cycle tainted-register-count) tuple, so a longer or more arithmetic-heavy encoding block can mechanically generate more points without exploring new behavior. The paper even says \"higher coverage does not guarantee more bugs,\" yet the 4.7x number is in the abstract. The bug-finding comparison is anecdotal—SpecDoctor found none in the replayed tests—so the number carries too much weight. That needs a fairer protocol: a neutral coverage metric or wall-clock time to first bug with a fixed budget.\n\nMinor concerns: diffIFT is an admitted under-approximation (Sec. 3.3); identical control values suppress control taints and miss leaks. Secret-flipping helps but doesn’t eliminate it. Manual liveness annotations are required—212 LoC on BOOM, 592 on XiangShan—a real portability cost. The artifact isn’t version-pinned, and there’s a citation mismatch in the related work.\n\nBottom line: the bug-finding claim holds up, the coverage claim doesn’t as stated. It deserves a serious referee, and acceptance should be conditioned on a revised comparison and pinned artifacts. I’d bring it to a reading group for the primitives and the CVEs, and I’d cite it for those—but not for the 4.7x.","headline":"Genuinely new primitives and five CVE-backed bugs, but the headline 4.7x coverage over SpecDoctor is built on the authors' own metric and doesn't hold up.","tokens_in":23382,"tokens_out":5068,"would_cite":true,"duration_ms":45509,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"DejaVuzz finds five new transient-execution bugs by giving a processor fuzzer memory swapping and differential taint tracking.","keywords":["transient execution vulnerabilities","processor fuzzing","RTL verification","dynamic information flow tracking","differential testing","speculative execution","microarchitectural side channels","pre-silicon security testing"],"falsifier":"Take a secret-dependent branch or multiplexer select whose outcome is identical for the two bit-flipped secrets DejaVuzz uses (for example, a condition that checks only the lowest bit while the two secrets differ only in upper bits), add a third secret that flips that control signal, and check whether DejaVuzz's taint log reports the leak for the third secret while staying silent on the original pair; a silent miss on the pair would confirm diffIFT's under-approximation and bound the bug-finding guarantee.","tokens_in":22358,"feed_emoji":"🐛","tokens_out":8777,"duration_ms":78398,"temperature":0.7,"pith_summary":"DejaVuzz is a pre-silicon fuzzer for transient execution vulnerabilities, the class of bugs behind Spectre and Meltdown, running on register-transfer-level designs of out-of-order processors. It argues that prior fuzzers fail for two reasons: they cannot freely arrange training code and transient code because both compete for the same addresses, and they cannot tell which microarchitectural changes were actually caused by the secret. To fix this, it time-shares a memory region between training and transient instruction sequences, and runs two copies of the processor with bit-flipped secrets, propagating taints only when the two copies disagree on a control signal. On two open-source RISC-V out-of-order cores it reports a 4.7x improvement in taint coverage over the leading baseline, near-zero training for most transient window types, and five previously unknown vulnerabilities that received six CVEs.","feed_headline":"Transient-execution fuzzer finds 5 new bugs in RISC-V cores","feed_subtitle":"Memory swapping plus differential taint tracking raises coverage 4.7x and exposes six CVEs in open cores.","key_machinery":"The central mechanisms are two operating primitives. Dynamic swappable memory, or swapMem, divides memory into shared, dedicated, and swappable regions; a trap handler flushes the instruction cache and loads a new instruction sequence into the swappable region between phases, so that training and transient code can share one address space without polluting each other. Differential information flow tracking, or diffIFT, instruments the RTL at its intermediate-representation level with shadow taint cells; for multiplexers, comparison cells, register enables, and memory reads and writes, control taints propagate only when the corresponding signal differs between two DUT instances holding bit-flipped secrets. The taint coverage matrix counts, per module and per clock cycle, how many registers are tainted, giving the fuzzer a feedback signal for mutation, while taint liveness annotations bind data buffers to their validity state registers so that stale data left in buffers is not reported as leakage.","core_discovery":"The paper's central claim is that transient execution bugs in complex out-of-order processors can be found systematically before silicon by giving the fuzzer two capabilities previous pre-silicon fuzzers lack: microarchitectural controllability via dynamic swappable memory and microarchitectural observability via differential information flow tracking. Dynamic swappable memory lets the fuzzer load training sequences and transient sequences into the same address space at different times, so it can trigger arbitrary transient windows, including backward branches and exception-driven windows that the prior state-of-the-art fuzzer discards, and then delete training packets that do not contribute. Differential information flow tracking instruments the RTL so that a tainted control signal only propagates its taint when two identical cores fed different secrets actually choose different values, which removes the control-flow over-tainting that makes prior taint trackers saturate. On this basis DejaVuzz defines a taint coverage matrix to guide mutation and taint liveness annotations to discard stale buffer contents, and reports five new transient execution vulnerabilities, Meltdown-Sampling, Phantom-RSB, Phantom-BTB, Spectre-Refetch, and Spectre-Reload, with six CVEs assigned across the two cores.","pith_inferences":["The paper does not explore this, but because diffIFT uses only two concrete secrets, its false-negative rate is governed by how often the secret pair lands on equal values at a secret-dependent control point; a natural extension would be to sweep several pairwise-different secrets per run or to substitute symbolic comparison at those control points.","If swapMem's scheduling can be mounted through a system-level mechanism such as DMA rather than a simulator trap handler, the same training/transient isolation could be applied to post-silicon or black-box processor testing, a possibility the paper only raises.","The reported 54-of-75 false-positive rate for the baseline suggests that stale-buffer artifacts dominate naive differential oracles; applying DejaVuzz's liveness-filtering logic to other cores should reproduce a similar drop in false positives, a testable prediction beyond the two processors in the paper."],"forward_implications":["If DejaVuzz is right, pre-silicon fuzzers can trigger all major classes of transient windows, including exception-driven, memory-disambiguation, branch-misprediction, indirect-jump, and return-address-misprediction windows, rather than a limited template subset.","Training overhead for a transient window drops to near zero for exception-type windows and to a few effective instructions for misprediction-type windows, because ineffective training packets are identified by re-simulation and discarded.","The differential taint approach damps control-flow over-tainting: a tainted selection signal is ignored unless two differently-secreted copies actually produce different selections, keeping taint counts low enough to serve as fuzzing coverage.","Taint liveness annotations can separate real leakages from stale-buffer artifacts, reducing false positives that otherwise make fuzzers spend iterations decoding unexploitable state.","Previously overlooked bugs, such as secret-dependent return-address-stack corruption and exception-time branch-target-buffer updates, become detectable in RTL, meaning real out-of-order cores without fixes could be at risk."],"supporting_citations":[{"why":"Supplies the state-of-the-art fuzzing baseline whose transient-window coverage, training overhead, and vulnerability findings are compared against.","marker":"[18]"},{"why":"Provides the RTL information-flow-tracking instrumentation and taint propagation policies that diffIFT adapts by gating control taints on cross-instance differences.","marker":"[37]"},{"why":"One of the prior template-based pre-silicon fuzzers whose Meltdown-only gadget scope motivates the need for a general transient-window generator.","marker":"[11]"},{"why":"The other template-based fuzzer, whose value-matching oracle cannot follow secrets after arithmetic, motivating diffIFT-based coverage.","marker":"[12]"},{"why":"Defines Spectre and the training-transient-window structure that DejaVuzz's packets reproduce for control-flow mispredictions.","marker":"[21]"},{"why":"Defines Meltdown and the exception-based transient window that DejaVuzz generalizes to access faults, page faults, and misalignment.","marker":"[25]"},{"why":"Describes Spectre-Rewind, the prior attack that two of the newly discovered vulnerabilities, instruction-address and load-port contention variants, extend.","marker":"[10]"},{"why":"A formal RTL verification approach for transient execution side channels; the paper notes that several new bugs escape its analysis, positioning fuzzing as a complementary check.","marker":"[9]"}],"fun_headline_variants":["Pre-silicon fuzzer DejaVuzz lifts transient bug coverage 4.7x","DejaVuzz: differential taint + swappable memory find 6 CVEs","Fuzzer for transient-execution bugs discovers 5 on RISC-V","With swappable memory and taint tracking, fuzzer exposes 6 CVEs","DejaVuzz fuzzer: dynamic memory and differential taint net 5 bugs"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The method assumes that two copies of the processor with bit-flipped secrets will show visibly different values on every secret-dependent control signal, so that any leak depending on a control decision will be tainted; if the chosen secret pair happens to agree on that signal, the leak is silently missed.","fun_headline_variants_meta":{"raw":{"variants":["Pre-silicon fuzzer DejaVuzz lifts transient bug coverage 4.7x","DejaVuzz: differential taint + swappable memory find 6 CVEs","Fuzzer for transient-execution bugs discovers 5 on RISC-V","With swappable memory and taint tracking, fuzzer exposes 6 CVEs","DejaVuzz fuzzer: dynamic memory and differential taint net 5 bugs"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001,"raw_usage":{"total_tokens":4301,"prompt_tokens":1084,"completion_tokens":3217,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":700,"completion_tokens_details":{"reasoning_tokens":3102}},"tokens_in":700,"tokens_out":3217,"duration_ms":22374,"temperature":1.0,"reasoning_tokens":3102,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T05:15:03.939366+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a secret-dependent branch or multiplexer select whose outcome is identical for the two bit-flipped secrets DejaVuzz uses (for example, a condition that checks only the lowest bit while the two secrets differ only in upper bits), add a third secret that flips that control signal, and check whether DejaVuzz's taint log reports the leak for the third secret while staying silent on the original pair; a silent miss on the pair would confirm diffIFT's under-approximation and bound the bug-finding guarantee.","supporting_citations":[{"cited_title":"Spec- doctor: Differential fuzz testing to find transient execution vulnerabil- ities","cited_arxiv_id":null,"evidence_quote":"Supplies the state-of-the-art fuzzing baseline whose transient-window coverage, training overhead, and vulnerability findings are compared against."},{"cited_title":"{CellIFT}: Leveraging cells for scalable and precise dynamic information flow tracking in {RTL}","cited_arxiv_id":null,"evidence_quote":"Provides the RTL information-flow-tracking instrumentation and taint propagation policies that diffIFT adapts by gating control taints on cross-instance differences."},{"cited_title":"Teesec: Pre-silicon vulnerability discovery for trusted ex- ecution environments","cited_arxiv_id":null,"evidence_quote":"One of the prior template-based pre-silicon fuzzers whose Meltdown-only gadget scope motivates the need for a general transient-window generator."},{"cited_title":"Introspectre: A pre-silicon framework for discovery and analysis of transient execution vulnerabilities","cited_arxiv_id":null,"evidence_quote":"The other template-based fuzzer, whose value-matching oracle cannot follow secrets after arithmetic, motivating diffIFT-based coverage."},{"cited_title":"Spectre attacks: Exploit- ing speculative execution","cited_arxiv_id":null,"evidence_quote":"Defines Spectre and the training-transient-window structure that DejaVuzz's packets reproduce for control-flow mispredictions."},{"cited_title":"Meltdown: Reading kernel memory from user space","cited_arxiv_id":null,"evidence_quote":"Defines Meltdown and the exception-based transient window that DejaVuzz generalizes to access faults, page faults, and misalignment."},{"cited_title":"Spectrerewind: Leak- ing secrets to past instructions","cited_arxiv_id":null,"evidence_quote":"Describes Spectre-Rewind, the prior attack that two of the newly discovered vulnerabilities, instruction-address and load-port contention variants, extend."},{"cited_title":"An exhaustive approach to detecting transient execution side channels in rtl designs of processors","cited_arxiv_id":null,"evidence_quote":"A formal RTL verification approach for transient execution side channels; the paper notes that several new bugs escape its analysis, positioning fuzzing as a complementary check."}],"review_version":1}