Pith. sign in

REVIEW 4 major objections 5 minor 26 references

ANTMAN: An Efficient and Interpretable RTL-Level Run-Time Detection Framework for Stealthy Branch Predictor Attacks on BOOM

T0 review · 4 major / 5 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read ANTMAN claims that a 16-rule hardware monitor mined from one attack trace can catch stealthy branch predictor attacks on BOOM RISC-V at 25–56% of attack completion, with zero false positives on the tested workloads.

desk verdict A plausible RTL-level proof of concept for branch predictor attack detection on BOOM, but the zero-false-positive and before-secret-disclosure claims outrun the evidence. read the letter →

arxiv 2608.09498 v1 pith:AC3LHFGO submitted 2026-08-10 cs.CR

Muhammad Hassan , Maria Mushtaq , Jaan Raik , Tara Ghasempouri This is my paper · ORCID
classification cs.CR
keywords branchpredictorattackRTL-leveldetectionassociationruleminingRISC-VBOOMruntimeside-channelTAGE
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper claims that stealthy branch predictor attacks on an out-of-order RISC-V core can be caught at run time by watching the coordinated pipeline-wide reaction they trigger, rather than by sampling performance counters. The authors mine 16 association rules from RTL signal traces of one attack variant and embed those rules in BOOM as a non-intrusive hardware monitor that counts rule activations and stops execution when all counts exceed a support threshold. They report that both the original attack and an unseen variant are detected before the attack completes, and that none of seven benign workloads, including branch-heavy ones, trips the monitor. The payoff is a secure-by-design, interpretable detection layer for RISC-V that sidesteps the limited counter registers, multiplexing, and coarse sampling that plague HPC-based detectors.

What carries the argument

The load-bearing mechanism is association rule mining over RTL signal traces: FP-Growth (Frequent Pattern Growth) compresses the trace into a pattern tree and extracts frequent itemsets, from which rules of the form X→Y are drawn with support ≥5% and confidence ≥90%. The 16 resulting rules couple 14 tapped signals spanning the GHR, NLP/BTB, direction-predictor, redirect, branch-update-broadcast, and pipeline-flush blocks, and they cluster into global branch misprediction, redirect/control-flow correction, and pipeline flush recovery. In hardware, each rule becomes a conjunction of tapped signals feeding a 16-bit counter in the RuleMonitor, and an assertion fires when every rule's counter exceeds the support threshold, halting execution without interfering with the processor pipeline.

What would settle it

Run the same monitor on a deliberately branch-heavy benign workload engineered to trigger many simultaneous mispredictions and pipeline flushes, or on a branch predictor attack variant that leaks through the predictor without producing a coordinated full-pipeline flush; if the assertion fires on the benign workload, or stays silent on that attack variant, the generality of the rule signature is refuted.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central discovery is that branch predictor attacks leave a repeatable, structured footprint in RTL signals: simultaneous global branch misprediction across multiple pipeline blocks, redirect of the frontend, and a coordinated full-pipeline flush. That footprint is captured by 16 association rules mined with FP-Growth from a single CBPA trace at 5% support and 90% confidence, grouped into three clusters (global misprediction, control-flow correction, and recovery). The rules are implemented as AND logic in a separate RuleMonitor.scala module instantiated in Core.scala, with a 16-bit counter per rule; when every rule's counter exceeds the predefined support threshold, an assertion terminates simulation. Under the simplified NLP configuration, both CBPA and IBPA are detected at 25% of attack completion; under the TAGE configuration, CBPA is detected at 25% with roughly 50% secret-recovery success, and the unseen IBPA variant at 56.25%. Across the tested computational, memory-intensive, and branch-heavy workloads, no benign execution is terminated, giving zero false positives under both predictor configurations.

Load-bearing premise

The load-bearing premise is that 16 association rules mined from a single CBPA attack trace, with 5% support and 90% confidence, define a signature that separates every branch predictor attack—including unseen variants—from every benign workload, including branch-heavy ones, under both NLP and TAGE predictor configurations.

Editorial extensions

If this is right

  • Detection happens early: under the simplified NLP configuration both CBPA and IBPA are terminated at 25% of attack execution, and under TAGE the unseen IBPA variant is stopped at 56.25%.
  • The monitor produces zero false positives on the seven evaluated benign workloads (dhrystone, mm, median, qsort, spmv, towers, vvadd) under both predictor configurations.
  • The detector generalizes to a previously unseen variant (IBPA) from rules learned only from CBPA, indicating family-level flexibility without retraining.
  • Because the monitor taps internal RTL signals directly, it avoids the restricted counter registers, multiplexing, and sampling tradeoffs that limit HPC-based runtime detectors.
  • The rules are interpretable: each alarm corresponds to a readable coupling of misprediction, redirect, and flush signals, so the detection is auditable by a security engineer.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The same offline mining plus embedded-monitor flow could transfer to other microarchitectural attacks on BOOM, such as Spectre-variant or fault-based side channels, provided those attacks also create a coordinating pipeline-wide signal signature; the transfer is untested in the paper.
  • The 5% support and 90% confidence thresholds, and the 16-rule set, come from a single CBPA trace, so a natural stress test is to sweep attack parameters and thresholds to map when the monitor stops detecting or starts firing on noisy branches.
  • The zero-false-positive result is scoped to seven standalone workloads; the camouflaged-attack setting (attack hidden inside a benign app) is explicitly out of scope, and the future-work windowed counter idea would be the direct way to extend toward that case.
  • If the method holds, RISC-V's open-source RTL could make a general 'rule monitor per attack family' a practical secure-by-design primitive, in contrast to closed x86/ARM cores where such internal signal access is impossible.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes ANTMAN, an RTL-level runtime detection framework for branch predictor attacks on the BOOM RISC-V processor. The methodology selects 14 RTL signals from branch-prediction-related pipeline blocks, mines 16 association rules from a single CBPA attack trace using FP-Growth with 5% minimum support and 90% minimum confidence, and embeds these rules as a non-intrusive hardware monitor with per-rule 16-bit counters and a conjunction-based assertion. The framework is evaluated offline and at runtime under both a simplified Next-Line Predictor (NLP) and a complex TAGE predictor configuration, with CBPA and IBPA attack workloads plus seven benign workloads. The paper reports detection at 25% of attack completion for CBPA under NLP and TAGE, 25% for IBPA under NLP, 56.25% for IBPA under TAGE, and zero false positives on the tested benign workloads, and claims termination before secret disclosure.

Significance. If the central claims hold, the work is a useful proof of concept: it is, to my knowledge, one of the first RTL-level runtime detectors for branch predictor attacks on an open RISC-V core, and it has the concrete advantage of using internal pipeline signals rather than sampled performance counters, which makes the detection interpretable and potentially fast. The included trace listings give concrete evidence that the detector fires during CBPA and IBPA executions, and the use of both NLP and TAGE configurations is a genuine strength. However, the paper's broad guarantees—zero false positives, termination before secret disclosure, and flexibility to unseen variants—are not supported by the current evidence, which is limited to seven benign workloads, one mined attack trace, and no held-out set, artifact, or overhead measurement.

major comments (4)
  1. [Section V.B and Section VI.A, Listing 1] The 16 association rules are mined from a single CBPA attack trace and then evaluated on the same CBPA trace, one IBPA variant, and seven benign workloads. This is an in-sample evaluation for CBPA, and the benign set is far too small to support the abstract's 'zero false positives' claim. The paper should provide a held-out workload set or cross-validation, report per-workload rule activation counts and margins above/below the activation threshold, and make the traces or rule-mining scripts available so the generalization claim can be checked.
  2. [Abstract and Section VI.B, Listing 2] The claim that execution is 'terminated before secret disclosure' is contradicted by Listing 2: under the NLP configuration, the CBPA trace prints four correct secret indices (Index 0 through Index 3) before the assertion fires at 25% of attack completion. Partial secret disclosure has therefore already occurred. The paper should either weaken this claim to 'detection before attack completion, with partial leakage possible' or provide a mechanism that prevents the leak of any secret bit, and it should quantify the residual leakage.
  3. [Figure 2 and Section V, Step 3] The monitor raises the alarm only when 'All Rule's Trigger' counters exceed the threshold, i.e., a conjunction of 16 learned rules. Since the rules are strongly correlated pipeline-wide misprediction, redirect, and flush signals, a branch-heavy benign workload or a slightly different attack variant could either fail one rule and evade detection or push all counters over threshold and cause a false positive. The manuscript never states the numeric activation threshold for the counters and gives no margin data between benign workload counter values and that threshold. This threshold and the margins are load-bearing for both the zero-false-positive claim and the detection-speed claim, and they must be specified.
  4. [Contribution 3, Section VI.C, and Section VII] The paper claims the approach has 'negligible performance overhead' and 'no speed-performance trade-off', but no overhead measurement is reported anywhere. Table VI has no overhead column, and Section VII explicitly defers power, performance, and area analysis to future work. Since the monitor is instantiated in Core.scala and adds 16 counters plus AND logic, at least a synthesis-area and simulation-speed comparison, or a clear statement that overhead is currently unmeasured, is needed before the overhead claim can stand.
minor comments (5)
  1. [Section II, Definitions 3 and 4] The support and confidence thresholds are cited to earlier papers rather than justified for this attack-detection context; a sentence explaining how 5% and 90% were chosen would improve reproducibility.
  2. [Tables III, IV, and V] Rule numbers restart in each cluster table, which is confusing when referring to 'Rule 1' in the text and in Figure 2; consider numbering the 16 rules globally.
  3. [Listings 2 and 3] The assertion message differs between the two listings ('Branch prediction related attack detected' vs. 'Any branch prediction related attack detected'); please make the monitor message a single fixed string or explain the difference.
  4. [Section VI.B and Table VII] The percentages '25%' and '56.25%' of attack completion are derived from the secret indices printed in the listings, but the text does not define how attack completion is measured (e.g., cycles, rounds, or secret bits recovered). Please define the metric explicitly.
  5. [References] References [19] and [25] appear to be the same paper, and reference [18]/[28] contains a typo ('neutral network' instead of 'neural network'); please correct and deduplicate.

Circularity Check

1 steps flagged · score 6.0 of 10

The CBPA detection result is fitted-input: the 16 rules are mined from the CBPA trace at 5% support and the monitor alarms when the same 5% support threshold is exceeded, so CBPA detection is an in-sample re-detection; only the IBPA result is partially independent.

  1. fitted input called prediction [Section V.B (Association Rule Mining-Based Feature Selection), Step 3 / Fig. 2 (rule monitor), Section VI.A (Offline Detection)]
    "From the data mining output, we obtained a set of 16 interpretable association rules based on predefined minimum support 5% and confidence 90% thresholds... The association rules are generated using one variant of branch predictor attack (CBPA) and evaluated against both attack variants (CBPA and IBPA) alongside all benign applications... stops execution when the activation count exceeds the prescribed support threshold."

    Each rule is a frequent itemset with at least 5% support in the single CBPA trace used for mining. The embedded monitor (Fig. 2) increments a counter whenever a rule triggers and raises the alarm only when all 16 counters exceed the same 'predefined Support Threshold' (5%) that was used as the FP-Growth minimum-support input. Replaying CBPA therefore satisfies the alarm condition by construction: every rule was selected precisely because it occurs at or above that threshold in that trace. Reporting 'CBPA detected 16/16' is a re-statement of the rule-selection criterion, not an independent prediction.

full rationale

The central derivation chain reduces at one load-bearing point: rules are fit to the CBPA trace (5% support, 90% confidence) and the alarm is defined as all 16 rule counters exceeding that same 5% support threshold, so CBPA detection is forced by construction. This is the fitted-input pattern. The IBPA detection under NLP (25%) and TAGE (56.25%) provides a partially independent check, preventing a score of 8 or higher; the seven benign workloads are too limited to support the broad zero-false-positive guarantee. Self-citations to [19]/[25] for the attack model and TAGE behavior are not load-bearing for the detection derivation. Separately, Listing 2 shows four secret indices printed before the assertion fires, which undercuts the 'terminates execution before secret disclosure' claim; that is a correctness/evidence concern, not a circularity.

Assumptions & free parameters 4 free parameters · 4 assumptions · 1 invented entities

The central detection result rests on several fitted quantities: support and confidence thresholds, an unquantified counter threshold, and a hand-selected set of 14 RTL signals. The attack model and the representativeness of benign workloads are domain assumptions. The rule monitor is a newly introduced hardware component with no independent evidence outside the paper's own simulation.

free parameters (4)
  • Minimum support threshold theta_s = 5%
    Chosen as input to FP-Growth in Definition 3; not derived from first principles. The detector's counter threshold appears to be linked to this value, effectively tuning the alarm to the attack trace.
  • Minimum confidence threshold theta_c = 90%
    Chosen as input to association rule generation in Definition 4; affects which rules survive into the hardware monitor.
  • Rule activation counter threshold = Not explicitly specified
    The monitor raises an assertion when all rule counters exceed a 'predefined support threshold' (Section V Step 3, Figure 2), but the numeric value is not given, and it is evidently derived from the CBPA trace.
  • Set of 14 monitored RTL signals = 14 signals from Table II
    Selected by domain knowledge as signals 'that may be affected by branch predictor attacks' (Section V, Step 2A); this selection constrains what the detector can see.
assumptions (4)
  • domain assumption The attack model of [19] (train, victim execution, probe) faithfully characterizes branch predictor attacks on BOOM.
    Section IV adopts the model without independent validation.
  • ad hoc to paper Rules mined from CBPA traces generalize to IBPA and other unseen variants and remain valid across NLP and TAGE configurations.
    Section VI.A generates rules from CBPA only, then applies them to IBPA and to TAGE; no argument beyond empirical co-occurrence is provided for generalization.
  • domain assumption The Verilator cycle-accurate simulation faithfully models timing and signal behavior of real BOOM hardware.
    All detection timings and secret-recovery percentages are measured in simulation (Section V Step 1), not on FPGA or silicon.
  • domain assumption Benign workloads tested (dhrystone, mm, median, qsort, spmv, towers, vvadd) are representative of benign branch behavior.
    Zero false positives are claimed from these seven workloads alone (Listing 1, Section VI).
invented entities (1)
  • Non-intrusive rule monitor (RuleMonitor.scala)
    purpose: Counts activations of 16 association rules on 14 tapped RTL signals and asserts an alarm when counters exceed the support threshold.
    The monitor exists only as a Chisel module in the paper's simulation flow; no FPGA synthesis, area report, or external validation is provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of ANTMAN: An Efficient and Interpretable RTL-Level Run-Time Detection Framework for Stealthy Branch Predictor Attacks on BOOM." pith.science (2026). https://pith.science/paper/AC3LHFGO

@misc{pith2026260809498,
  author       = {Pith},
  title        = {Pith review of: ANTMAN: An Efficient and Interpretable RTL-Level Run-Time Detection Framework for Stealthy Branch Predictor Attacks on BOOM},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/AC3LHFGO}},
  note         = {Machine review of arXiv:2608.09498}
}
read the original abstract

Runtime detection of microarchitectural side channel attacks remains significantly underexplored in RISCV compared with x86 and ARM ISAs, posing a serious threat to critical applications. State-of-the-art branch predictor attacks bypass traditional data and instruction caches by directly exploiting the state of internal history tables, making them inherently stealthy. Recent research has explored offline detection of microarchitectural attacks on RISC-V; however, efficient runtime detection of microarchitectural attacks on RISC-V hardware remains significantly unaddressed. State-of-the-art hardware-based runtime detection solutions leverage hardware performance counters (HPCs) but suffer from a restricted set of counter registers and tradeoffs between detection accuracy, detection speed, and sampling granularity, making them impractical for stealthy attacks. Moreover, sampling HPCs after distinct intervals leaves intermediate relationships between different microarchitectural blocks unobserved. Additionally, proprietary x86 and ARM ISAs constrain researchers from modifying processor microarchitectural designs. To address these limitations, we propose the first secure-by-design, highly interpretable, non-intrusive, RTL-level runtime detection solution for stealthy branch predictor attacks on BOOM RISC-V, evaluated under both simplified Next-Line Predictor (NLP) and complex TAGE predictor configurations. The attack detection relies on association rules extracted offline and embedded in hardware as a non-intrusive rule monitor that enables runtime detection. The proposed approach achieves excellent detection speed, terminates execution before secret disclosure, and produces zero false positives while remaining flexible for detecting previously unseen variants within the same family of branch predictor attacks.

Figures

Figures reproduced from arXiv: 2608.09498 by the authors.

Figure 1
Figure 1. ANTMAN (Secure by design RTL level run-time detection framework) [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Non-Intrusive Rule Monitor chitectural blocks, enabling coordinated control-flow recovery. When speculation fails, redirect decisions redirect instruction fetch to the correct path and initiate recovery by propagating control-flow correction across the processor pipeline. 3) Global Pipeline Flush (Recovery): The association rules in the third cluster (Table V) highlight strong coordination among pipeline flush signa… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

26 extracted references · 25 canonical work pages

  1. [1]

    Spectre attacks: exploiting speculative execution,

    P. Kocher, J. Horn, A. Fogh, D. Genkin, D. Gruss, W. Haas, M. Hamburg, M. Lipp, S. Mangard, T. Prescher, M. Schwarz, and Y . Yarom, “Spectre attacks: exploiting speculative execution,”Commun. ACM, vol. 63, no. 7, p. 93–101, Jun. 2020. [Online]. Available: https://doi.org/10.1145/3399742

    doi:10.1145/3399742 2020

  2. [2]

    Meltdown: reading kernel memory from user space,

    M. Lipp, M. Schwarz, D. Gruss, T. Prescher, W. Haas, A. Fogh, J. Horn, S. Mangard, P. Kocher, D. Genkin, Y . Yarom, and M. Hamburg, “Meltdown: reading kernel memory from user space,” inProceedings of the 27th USENIX Conference on Security Symposium, ser. SEC’18. USA: USENIX Association, 2018, p. 973–990

    work page 2018

  3. [3]

    The kingsguard os-level mitigation against cache side-channel attacks using runtime detection,

    M. Mushtaq, M. M. Yousaf, M. K. Bhatti, V . Lapotre, and G. Gogniat, “The kingsguard os-level mitigation against cache side-channel attacks using runtime detection,”Annals of Telecommunications, vol. 77, no. 11–12, pp. 731–747, 2022. [Online]. Available: https://doi.org/10.1007/s12243-021-00906-3

    work page doi:10.1007/s12243-021-00906-3 2022

  4. [4]

    Nights-watch: a cache-based side-channel intrusion detector using hardware performance counters,

    M. Mushtaq, A. Akram, M. K. Bhatti, M. Chaudhry, V . Lapotre, and G. Gogniat, “Nights-watch: a cache-based side-channel intrusion detector using hardware performance counters,” inProceedings of the 7th International Workshop on Hardware and Architectural Support for Security and Privacy, ser. HASP ’18. New York, NY , USA: Association for Computing Machine...

    work page arXiv 2018

  5. [5]

    Whisper: A tool for run-time detection of side-channel attacks,

    M. Mushtaq, J. Bricq, M. K. Bhatti, A. Akram, V . Lapotre, G. Gogniat, and P. Benoit, “Whisper: A tool for run-time detection of side-channel attacks,”IEEE Access, vol. 8, pp. 83 871–83 900, 2020

    work page 2020

  6. [6]

    Fight hardware with hardware: Systemwide detection and mitigation of side-channel attacks using performance counters,

    S. Carn `a, S. Ferracci, F. Quaglia, and A. Pellegrini, “Fight hardware with hardware: Systemwide detection and mitigation of side-channel attacks using performance counters,”Digital Threats, vol. 4, no. 1, Mar. 2023. [Online]. Available: https://doi.org/10.1145/3519601

    work page doi:10.1145/3519601 2023

  7. [7]

    Victims can be saviors: A machine learning–based detection for micro-architectural side-channel attacks,

    M. Alam, S. Bhattacharya, and D. Mukhopadhyay, “Victims can be saviors: A machine learning–based detection for micro-architectural side-channel attacks,”J. Emerg. Technol. Comput. Syst., vol. 17, no. 2, Jan. 2021. [Online]. Available: https://doi.org/10.1145/3439189

    work page doi:10.1145/3439189 2021

  8. [8]

    Madman: Detection of software attacks targeting hardware vulnerabilities,

    N. F. Polychronou, P.-H. Thevenon, M. Puys, and V . Beroulle, “Madman: Detection of software attacks targeting hardware vulnerabilities,” in2021 24th Euromicro Conference on Digital System Design (DSD), 2021, pp. 355–362

    work page 2021

Show all 26 references
  1. [9]

    Specdefender: Transient execution attack defender using performance counters,

    A. Choudhari, S. Guilley, and K. Karray, “Specdefender: Transient execution attack defender using performance counters,” inProceedings of the 2022 Workshop on Attacks and Solutions in Hardware Security, ser. ASHES’22. New York, NY , USA: Association for Computing Machinery, 20...

    2022

  2. [10]

    Sok: The challenges, pitfalls, and perils of using hardware performance counters for security,

    S. Das, J. Werner, M. Antonakakis, M. Polychronakis, and F. Monrose, “Sok: The challenges, pitfalls, and perils of using hardware performance counters for security,” in2019 IEEE Symposium on Security and Privacy (SP), 2019, pp. 20–38

    2019

  3. [11]

    Challenges of Using Performance Counters in Security Against Side-Channel Leakage,

    M. Mushtaq, P. Benoit, and U. Farooq, “Challenges of Using Performance Counters in Security Against Side-Channel Leakage,” in CYBER 2020 - 5th International Conference on Cyber-Technologies and Cyber-Systems, Nice, France, Oct. 2020. [Online]. Available: https://hal.science/ha...

    2020

  4. [12]

    Sok: Can we really detect cache side-channel attacks by monitoring performance counters?

    W. Kosasih, Y . Feng, C. Chuengsatiansup, Y . Yarom, and Z. Zhu, “Sok: Can we really detect cache side-channel attacks by monitoring performance counters?” inProceedings of the 19th ACM Asia Conference on Computer and Communications Security, ser. ASIA CCS ’24. New York, NY , ...

    2024 doi

  5. [13]

    A security risc: Microarchitectural attacks on hardware risc-v cpus,

    L. Gerlach, D. Weber, R. Zhang, and M. Schwarz, “A security risc: Microarchitectural attacks on hardware risc-v cpus,” in2023 IEEE Symposium on Security and Privacy (SP), 2023, pp. 2321–2338

    2023

  6. [15]

    Assessing security risc: Analyzing flush+ fault attack on risc- v using gem5 simulator,

    ——, “Assessing security risc: Analyzing flush+ fault attack on risc- v using gem5 simulator,” inInternational Conference on Security and Cryptography (SECRYPT), 2025

    2025

  7. [16]

    Machine learning-based detection of microarchitectural attacks on risc-v via gem5,

    A. Palumbo, “Machine learning-based detection of microarchitectural attacks on risc-v via gem5,” inProceedings of TechDefense 2025 - IEEE International Workshop on Technologies for Defense and Security, Rome, Italy, November 2025, pp. 1–6, https://hal.sciencehal-05288651

    2025

  8. [17]

    Drsam: Detection of fault-based microarchitectural side-channel attacks in risc-v using statistical preprocessing and association rule mining,

    M. Hassan, M. Mushtaq, J. Raik, and T. Ghasempouri, “Drsam: Detection of fault-based microarchitectural side-channel attacks in risc-v using statistical preprocessing and association rule mining,”

  9. [18]

    Spectre attack detection with neutral network on risc- v processor,

    A.-T. Le, T.-T. Hoang, B.-A. Dao, A. Tsukamoto, K. Suzaki, and C.-K. Pham, “Spectre attack detection with neutral network on risc- v processor,” in2022 IEEE International Symposium on Circuits and Systems (ISCAS), 2022, pp. 2467–2471

    2022

  10. [21]

    Anomalous file system activity detection through temporal association rule mining

    M. R. H. Iman, P. Chikul, G. Jervan, H. Bahsi, and T. Ghasempouri, “Anomalous file system activity detection through temporal association rule mining.” inICISSP, 2023, pp. 733–740

    2023

  11. [22]

    An automatic approach to evaluate assertions’ quality based on data-mining metrics,

    T. Ghasempouri, S. Payandeh Azad, B. Niazmand, and J. Raik, “An automatic approach to evaluate assertions’ quality based on data-mining metrics,” in2018 IEEE International Test Conference in Asia (ITC-Asia), 2018, pp. 61–66

    2018

  12. [23]

    Verilator: The Fastest Verilog/SystemVerilog Simulator,

    W. Snyder, “Verilator: The Fastest Verilog/SystemVerilog Simulator,” https://www.veripool.org/verilator, 2023, accessed: 2024

    2023

  13. [24]

    SonicBOOM: The 3rd generation Berkeley out-of-order machine,

    J. Zhao, B. Korpan, A. Gonzalez, and K. Asanovic, “SonicBOOM: The 3rd generation Berkeley out-of-order machine,” inFourth Workshop on Computer Architecture Research with RISC-V (CARRV), May 2020

    2020

  14. [25]

    Microarchitectural espionage: Fpga-based security analysis of branch prediction in risc-v out-of-order cores,

    M. Khan, M. E. Bin Mohd Shahfie, M. Mushtaq, R. Pacalet, and L. Apvrille, “Microarchitectural espionage: Fpga-based security analysis of branch prediction in risc-v out-of-order cores,” in2026 14th Interna- tional Symposium on Digital Forensics and Security (ISDFS), 2026, pp. 1–7

    2026

  15. [26]

    Leveraging gem5 and machine learning for end- to-end detection of cache-based side-channel attack patterns,

    M. Awais, M. Mushtaq, L. Naviner, F. Bruguier, P. Benoit, and J. Haj-Yahya, “Leveraging gem5 and machine learning for end- to-end detection of cache-based side-channel attack patterns,” in PROOFS 2025 - 13th International Workshop on Security Proofs for Embedded Systems, Kuala...

    2025

  16. [27]

    Side-channel attack detection using gem5 and machine learning: A case study on fault-based attacks in risc-v,

    M. Khan, M. Mushtaq, R. Pacalet, and L. Apvrille, “Side-channel attack detection using gem5 and machine learning: A case study on fault-based attacks in risc-v,” in2025 IEEE 31st International Symposium on On- Line Testing and Robust System Design (IOLTS), 2025, pp. 1–5

    2025

  17. [28]

    Spectre attack detection with neutral network on risc-v processor,

    T.-T. Hoang, B.-A. Dao, A. P. Tsukamoto, K. Suzaki, and C.-K. Pham, “Spectre attack detection with neutral network on risc-v processor,” in Proceedings of the 2022 IEEE International Symposium on Circuits and Systems (ISCAS), Austin, TX, USA, 2022, pp. 2467–2471

    2022

  18. [2025]

    Available: https://arxiv.org/abs/2510.18612

    [Online]. Available: https://arxiv.org/abs/2510.18612

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.