pith. sign in

arxiv: 2502.09139 · v3 · submitted 2025-02-13 · 💻 cs.CR

Zebrafix: Mitigating Memory-Centric Side-Channel Leakage via Interleaving

Pith reviewed 2026-05-23 03:29 UTC · model grok-4.3

classification 💻 cs.CR
keywords ciphertext side-channelssilent storesmemory interleavingconstant-time cryptographycompiler mitigationmemory-centric side-channelsside-channel countermeasures
0
0 comments X

The pith

Interleaving counters with stored data mitigates both ciphertext side-channels and silent stores in constant-time code.

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

The paper defines design choices and requirements that allow interleaving of data with counter values to serve as a generic mitigation for ciphertext side-channel leakage. It realizes these choices in Zebrafix, a compiler tool that automatically ensures freshness of memory stores. Evaluation on cryptographic workloads shows that interleaving delivers better performance than prior mitigation techniques, though at the price of increased implementation complexity. The authors further argue that ciphertext side-channels and silent stores form a single broader class of memory-centric side-channels, so that the same interleaving mechanism addresses both.

Core claim

Zebrafix is a compiler-based tool that interleaves data with fresh counter values on every memory store. This ensures that ciphertext values are never reused, thereby closing ciphertext side-channel leakage. Under the unified category of memory-centric side-channels the same mechanism also prevents silent stores. The approach outperforms earlier mitigation methods on performance while requiring careful engineering to keep overheads manageable.

What carries the argument

Zebrafix compiler pass that interleaves each data store with a fresh counter value to guarantee ciphertext freshness.

If this is right

  • Interleaving achieves lower overhead than the three previously proposed ciphertext side-channel mitigations.
  • The same interleaving technique also stops silent-store leakage once both problems are viewed as memory-centric side-channels.
  • Constant-time cryptographic code can be protected against an additional class of memory-based leaks without manual source changes.
  • Practical deployment requires accepting higher engineering complexity to realize the performance benefit.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Library maintainers could adopt the compiler pass to protect entire code bases rather than individual primitives.
  • The memory-centric framing may suggest analogous interleaving defenses for non-cryptographic code that must resist memory observation.
  • Simplifying the current high-complexity implementation would widen the set of platforms on which the technique becomes attractive.

Load-bearing premise

The design choices and requirements chosen for interleaving suffice to deliver generic, practical mitigation across real cryptographic workloads without creating new vulnerabilities or unacceptable overheads.

What would settle it

A concrete test in which Zebrafix either allows observable ciphertext reuse on a real workload, exceeds the performance cost of alternative mitigations, or introduces a new leak would show the central claim to be false.

Figures

Figures reproduced from arXiv: 2502.09139 by Anna P\"atschke, Jan Wichelmann, Thomas Eisenbarth.

Figure 2
Figure 2. Figure 2: Ciphertext side-channel leakage in ct-swap based on [36, p. 3]. Ciphertexts are depicted in different shades of the memory address block. Although an attacker can only see ciphertexts of the values in arrays a and b, a ciphertext change leaks the value of the secret decision bit s during the ct-swap. and collision attack, whereby both rely on monitoring repeated write accesses to the same memory address. T… view at source ↗
Figure 1
Figure 1. Figure 1: Constant-time swap of two arrays a and b. s, the contents of two arrays a and b are swapped. The proce￾dure is shown in Figure 1a. The secret bit is used for building a mask value, extended to a machine-sized word that either resembles 0x00...00 or 0xFF...FF (line 1). With the mask, an intermediate value delta is set to propagate the information whether a and b are to be swapped (line 2). Thereby, in lines… view at source ↗
Figure 3
Figure 3. Figure 3: Silent store leakage in ct-swap. If the secret decision bit s is unset, the value to be written to the memory address is the same as the already contained one. Therefore, silent store optimizations drop the memory write. The constant-time properties of the ct-swap are violated as an attacker can observe whether a memory write happened or not. III. PREVENTING CIPHERTEXT SIDE-CHANNELS To counter ciphertext s… view at source ↗
Figure 4
Figure 4. Figure 4: Interleaving data and counter values in memory. In [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: ZEBRAFIX toolchain. The developer marks sensitive workloads via function annotations. Then, the middle end passes add the main interleaving capabilities to the code. In the back end, the register allocation is adapted to prefer spilling to vector registers over spilling to the stack. With memory traces, the binary can be checked for leaky writes. performance; and combined with a binary-level assessment, an… view at source ↗
Figure 6
Figure 6. Figure 6: Interleaving counter values and small data chunks in [PITH_FULL_IMAGE:figures/full_fig_p007_6.png] view at source ↗
Figure 8
Figure 8. Figure 8: Instrumentation of a malloc call that allocates a byte array. The allocation size is adjusted by the compiler to fit the additional counters and padding. leakages in accordance with known leaking algorithms. That way, the developer can determine whether secret data would be spilled to the stack and can apply some source-level mitigations like storing the affected data as global variables instead. Afterward… view at source ↗
Figure 9
Figure 9. Figure 9: Data memory-dependent prefetcher (DMP) leak [PITH_FULL_IMAGE:figures/full_fig_p014_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Interleaving data and values for freshness and DMP [PITH_FULL_IMAGE:figures/full_fig_p015_10.png] view at source ↗
read the original abstract

Constant-time code has become the de-facto standard for secure cryptographic implementations. However, some memory-based leakage classes such as ciphertext side-channels and silent stores remain unaddressed. Prior work proposed three different methods for ciphertext side-channel mitigation, for which one, the practicality of interleaving data with counter values, remains to be explored. To close this gap, we define design choices and requirements to leverage interleaving for a generic ciphertext side-channel mitigation. Based on these results, we implement Zebrafix, a compiler-based tool to ensure freshness of memory stores. We evaluate Zebrafix and find that interleaving can perform much better than other ciphertext side-channel mitigations, at the cost of a high practical complexity. We further observe that ciphertext side-channels and silent stores belong to a broader attack category: memory-centric side-channels. Under this unified view, we show that interleaving-based ciphertext side-channel mitigations can be used to prevent silent stores as well.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 0 minor

Summary. The paper claims that defining specific design choices and requirements for interleaving data with counter values enables a generic mitigation of ciphertext side-channels; the resulting compiler-based tool Zebrafix achieves better performance than prior mitigations (at high practical complexity) and, under a unified memory-centric side-channel view, can also prevent silent stores.

Significance. If the evaluation and sufficiency arguments hold, the work would offer a performance-competitive compiler technique for two related memory-based leakage classes in constant-time crypto code, potentially reducing reliance on less efficient prior mitigations while unifying the attack surface.

major comments (2)
  1. [Abstract] Abstract and evaluation description: the central claim of performance gains over prior ciphertext mitigations plus dual mitigation of silent stores rests on an asserted evaluation, yet the provided text supplies no concrete details on benchmarks, threat models, comparison baselines, or overhead measurements, preventing verification of the reported advantages.
  2. [Design choices] Design choices and requirements section: the assertion that the defined choices for ensuring store freshness via interleaving are sufficient for generic, practical mitigation across real workloads (without new leakage vectors such as compiler interactions or combined access patterns, and with tolerable overhead) is load-bearing for both the performance and unified-view claims, but the manuscript provides no independent check or falsification test for these sufficiency conditions.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback. We address the two major comments point by point below, indicating where revisions to the manuscript are warranted.

read point-by-point responses
  1. Referee: [Abstract] Abstract and evaluation description: the central claim of performance gains over prior ciphertext mitigations plus dual mitigation of silent stores rests on an asserted evaluation, yet the provided text supplies no concrete details on benchmarks, threat models, comparison baselines, or overhead measurements, preventing verification of the reported advantages.

    Authors: We agree that the abstract as written does not contain the requested concrete details. The full manuscript includes a dedicated evaluation section that specifies the benchmarks (constant-time cryptographic primitives), threat model (memory-centric side-channels), comparison baselines (prior ciphertext mitigations), and measured overheads demonstrating performance advantages. To resolve the concern, we will revise the abstract to incorporate representative quantitative results and a concise description of the evaluation setup. revision: yes

  2. Referee: [Design choices] Design choices and requirements section: the assertion that the defined choices for ensuring store freshness via interleaving are sufficient for generic, practical mitigation across real workloads (without new leakage vectors such as compiler interactions or combined access patterns, and with tolerable overhead) is load-bearing for both the performance and unified-view claims, but the manuscript provides no independent check or falsification test for these sufficiency conditions.

    Authors: The design choices are motivated by a systematic requirements analysis that addresses store freshness and potential new leakage vectors, including compiler interactions and access-pattern combinations; these arguments are presented in the manuscript together with the Zebrafix implementation. We acknowledge that an explicit independent falsification test would strengthen the sufficiency claim. We will expand the section with additional discussion of edge cases and validation steps performed, while noting that a full new experimental falsification campaign lies outside the current scope. revision: partial

Circularity Check

0 steps flagged

No significant circularity; claims rest on implementation and evaluation

full rationale

The paper defines design choices for interleaving-based mitigation, implements Zebrafix as a compiler tool, and evaluates it empirically on cryptographic workloads. No equations, derivations, fitted parameters, or mathematical predictions appear in the provided text. Central claims about performance gains and unified memory-centric side-channel view are supported by direct implementation results rather than any reduction to self-citations, ansatzes, or renamed known results. The derivation chain is therefore self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The work rests on the domain assumption that constant-time coding is the baseline standard and that memory stores can be made fresh via interleaving without new side effects; no free parameters or invented entities are introduced.

axioms (1)
  • domain assumption Constant-time code is the de-facto standard for secure cryptographic implementations.
    Stated as background in the opening sentence of the abstract.

pith-pipeline@v0.9.0 · 5704 in / 1214 out tokens · 28823 ms · 2026-05-23T03:29:13.090608+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

42 extracted references · 42 canonical work pages

  1. [1]

    Not All Data are Created Equal: Data and Pointer Prioritization for Scalable Protection Against Data-Oriented Attacks,

    S. Ahmed, H. Liljestrand, H. Jamjoom, M. Hicks, N. Asokan, and D. Yao, “Not All Data are Created Equal: Data and Pointer Prioritization for Scalable Protection Against Data-Oriented Attacks,” in 32nd USENIX Security Symposium . USENIX Association, 2023. [Online]. Available: https://www.usenix.org/conference/usenixsecurity 23/presentation/ahmed-salman

  2. [2]

    Verifying Constant-Time Implementations,

    J. B. Almeida, M. Barbosa, G. Barthe, F. Dupressoir, and M. Emmi, “Verifying Constant-Time Implementations,” in 25th USENIX Security Symposium, T. Holz and S. Savage, Eds. USENIX Association, 2016, pp. 53–70. [Online]. Available: https://www.usenix.org/conference/usen ixsecurity16/technical-sessions/presentation/almeida

  3. [3]

    AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More

    AMD, “AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More.” [Online]. Available: https://www.amd.com/syst em/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity -protection-and-more.pdf

  4. [4]

    SEV Secure Nested Paging Firmware ABI Specification

    AMD, “SEV Secure Nested Paging Firmware ABI Specification.” [Online]. Available: https://www.amd.com/content/dam/amd/en/docum ents/epyc-technical-docs/specifications/56860.pdf

  5. [5]

    Andriesse, Practical Binary Analysis: Build Your Own Linux Tools for Binary Instrumentation, Analysis, and Disassembly

    D. Andriesse, Practical Binary Analysis: Build Your Own Linux Tools for Binary Instrumentation, Analysis, and Disassembly . No Starch Press, 2018

  6. [6]

    DIT: Data Independent Timing

    ARM, “DIT: Data Independent Timing.” [Online]. Available: https: //developer.arm.com/documentation/ddi0601/2024-06/AArch64-Registe rs/DIT--Data-Independent-Timing

  7. [7]

    Testing Side-Channel Security of Cryptographic Implementations Against Future Microarchitectures,

    G. Barthe, M. B ¨ohme, S. Cauligi, C. Chuengsatiansup, D. Genkin, M. Guarnieri, D. M. Romero, P. Schwabe, D. Wu, and Y . Yarom, “Testing Side-Channel Security of Cryptographic Implementations Against Future Microarchitectures,” in 2024 ACM SIGSAC Conference on Computer and Communications Security (CCS) . ACM, 2024, pp. 1076–1090. [Online]. Available: http...

  8. [8]

    ARMore: Pushing Love Back Into Binaries,

    L. D. Bartolomeo, H. Moghaddas, and M. Payer, “ARMore: Pushing Love Back Into Binaries,” in 32nd USENIX Security Symposium , J. A. Calandrino and C. Troncoso, Eds. USENIX Association, 2023, pp. 6311–6328. [Online]. Available: https://www.usenix.org/conference/us enixsecurity23/presentation/di-bartolomeo

  9. [9]

    MicroPro- filer: Principled Side-Channel Mitigation through Microarchitectural Profiling,

    M. Bognar, H. Winderix, J. V . Bulck, and F. Piessens, “MicroPro- filer: Principled Side-Channel Mitigation through Microarchitectural Profiling,” in 8th IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, 2023, pp. 651–670

  10. [10]

    GoFetch: Breaking Constant- Time Cryptographic Implementations Using Data Memory-Dependent Prefetchers,

    B. Chen, Y . Wang, P. Shome, C. W. Fletcher, D. Kohlbrenner, R. Paccagnella, and D. Genkin, “GoFetch: Breaking Constant- Time Cryptographic Implementations Using Data Memory-Dependent Prefetchers,” in 33rd USENIX Security Symposium . USENIX Association, 2024. [Online]. Available: https://www.usenix.org/c onference/usenixsecurity24/presentation/chen-boru

  11. [11]

    Binsec/Rel: Symbolic Binary Analyzer for Security with Applications to Constant-Time and Secret- Erasure,

    L. Daniel, S. Bardin, and T. Rezk, “Binsec/Rel: Symbolic Binary Analyzer for Security with Applications to Constant-Time and Secret- Erasure,” ACM Trans. Priv. Secur., vol. 26, no. 2, pp. 11:1–11:42, 2023

  12. [12]

    CipherH: Automated Detection of Ciphertext Side-channel Vulnerabilities in Cryptographic Implementations,

    S. Deng, M. Li, Y . Tang, S. Wang, S. Yan, and Y . Zhang, “CipherH: Automated Detection of Ciphertext Side-channel Vulnerabilities in Cryptographic Implementations,” in 32nd USENIX Security Symposium , J. A. Calandrino and C. Troncoso, Eds. USENIX Association, 2023, pp. 6843–6860. [Online]. Available: https://www.usenix.org/conferenc e/usenixsecurity23/pr...

  13. [13]

    RetroWrite: Statically Instrumenting COTS Binaries for Fuzzing and Sanitization,

    S. Dinesh, N. Burow, D. Xu, and M. Payer, “RetroWrite: Statically Instrumenting COTS Binaries for Fuzzing and Sanitization,” in 2020 IEEE Symposium on Security and Privacy (S&P) . IEEE, 2020, pp. 1497–1511

  14. [14]

    Hardware Store Elimination

    T. Downs, “Hardware Store Elimination.” [Online]. Available: https: //travisdowns.github.io/blog/2020/05/13/intel-zero-opt.html

  15. [15]

    Avoiding Instruction-Centric Microarchitectural Tim- ing Channels Via Binary-Code Transformations,

    M. Flanders, R. K. Sharma, A. E. Michael, D. Grossman, and D. Kohlbrenner, “Avoiding Instruction-Centric Microarchitectural Tim- ing Channels Via Binary-Code Transformations,” in 2024 Architectural Support for Programming Languages and Operating Systems (ASPLOS). ACM, 2024

  16. [16]

    A Systematic Evaluation of Automated Tools for Side- Channel Vulnerabilities Detection in Cryptographic Libraries,

    A. Geimer, M. Vergnolle, F. Recoules, L. Daniel, S. Bardin, and C. Maurice, “A Systematic Evaluation of Automated Tools for Side- Channel Vulnerabilities Detection in Cryptographic Libraries,” in 2023 ACM SIGSAC Conference on Computer and Communications Security (CCS), W. Meng, C. D. Jensen, C. Cremers, and E. Kirda, Eds. ACM, 2023, pp. 1690–1704

  17. [17]

    Data Dependent Prefetcher

    Intel, “Data Dependent Prefetcher.” [Online]. Available: https://www.in tel.com/content/www/us/en/developer/articles/technical/software-securit y-guidance/technical-documentation/data-dependent-prefetcher.html

  18. [18]

    Data Operand Independent Timing Instruction Set Architecture (ISA) Guidance

    Intel, “Data Operand Independent Timing Instruction Set Architecture (ISA) Guidance.” [Online]. Available: https://www.intel.com/content/ www/us/en/developer/articles/technical/software-security-guidance/best -practices/data-operand-independent-timing-isa-guidance.html

  19. [19]

    LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation,

    C. Lattner and V . S. Adve, “LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation,” in 2nd IEEE / ACM International Symposium on Code Generation and Optimization (CGO) . IEEE Computer Society, 2004, pp. 75–88

  20. [20]

    On the Value Locality of Store Instructions,

    K. M. Lepak and M. H. Lipasti, “On the Value Locality of Store Instructions,” in ACM/IEEE 27th International Symposium on Computer Architecture (ISCA). IEEE Computer Society, 2000

  21. [21]

    A Systematic Look at Ciphertext Side Channels on AMD SEV-SNP,

    M. Li, L. Wilke, J. Wichelmann, T. Eisenbarth, R. Teodorescu, and Y . Zhang, “A Systematic Look at Ciphertext Side Channels on AMD SEV-SNP,” in 2022 IEEE Symposium on Security and Privacy (S&P) . IEEE, 2022, pp. 337–351

  22. [22]

    CipherLeaks: Breaking Constant-time Cryptography on AMD SEV via the Ciphertext Side Channel,

    M. Li, Y . Zhang, H. Wang, K. Li, and Y . Cheng, “CipherLeaks: Breaking Constant-time Cryptography on AMD SEV via the Ciphertext Side Channel,” in 30th USENIX Security Symposium , M. Bailey and R. Greenstadt, Eds. USENIX Association, 2021, pp. 717–732. [Online]. Available: https://www.usenix.org/conference/usenixsecurity 21/presentation/li-mengyuan

  23. [23]

    Pin: Building Customized Program Analysis Tools with Dynamic Instrumentation,

    C. Luk, R. S. Cohn, R. Muth, H. Patil, A. Klauser, P. G. Lowney, S. Wal- lace, V . J. Reddi, and K. M. Hazelwood, “Pin: Building Customized Program Analysis Tools with Dynamic Instrumentation,” in 2005 ACM SIGPLAN International Conference on Programming Language Design and Implementation (PLDI) , V . Sarkar and M. W. Hall, Eds. ACM, 2005, pp. 190–200

  24. [24]

    MemJam: A False Dependency Attack Against Constant-Time Crypto Implemen- tations,

    A. Moghimi, J. Wichelmann, T. Eisenbarth, and B. Sunar, “MemJam: A False Dependency Attack Against Constant-Time Crypto Implemen- tations,” Int. J. Parallel Program., vol. 47, no. 4, pp. 538–570, 2019

  25. [25]

    Mitigating Data Leakage by Protecting Memory-Resident Sensitive Data,

    T. Palit, F. Monrose, and M. Polychronakis, “Mitigating Data Leakage by Protecting Memory-Resident Sensitive Data,” in 35th Annual Computer Security Applications Conference (ACSAC) . ACM, 2019

  26. [26]

    DynPTA: Combining Static and Dynamic Analysis for Practical Selective Data Protection,

    T. Palit, J. F. Moon, F. Monrose, and M. Polychronakis, “DynPTA: Combining Static and Dynamic Analysis for Practical Selective Data Protection,” in 2021 IEEE Symposium on Security and Privacy (S&P) . IEEE, 2021, pp. 1919–1937

  27. [27]

    CoDaRR: Continuous Data Space Randomization against Data-Only Attacks,

    P. Rajasekaran, S. Crane, D. Gens, Y . Na, S. V olckaert, and M. Franz, “CoDaRR: Continuous Data Space Randomization against Data-Only Attacks,” in 2020 ACM Asia Conference on Computer and Communica- tions Security (ASIA CCS) , H. Sun, S. Shieh, G. Gu, and G. Ateniese, Eds. ACM, 2020, pp. 494–505

  28. [28]

    Util::Lookup: Exploiting Key Decoding in Cryptographic Libraries,

    F. Sieck, S. Berndt, J. Wichelmann, and T. Eisenbarth, “Util::Lookup: Exploiting Key Decoding in Cryptographic Libraries,” in 2021 ACM SIGSAC Conference on Computer and Communications Security (CCS) , Y . Kim, J. Kim, G. Vigna, and E. Shi, Eds. ACM, 2021, pp. 2456–2473

  29. [29]

    TeeJam: Sub-Cache-Line Leakages Strike Back,

    F. Sieck, Z. Zhang, S. Berndt, C. Chuengsatiansup, T. Eisenbarth, and Y . Yarom, “TeeJam: Sub-Cache-Line Leakages Strike Back,” IACR Trans. Cryptogr. Hardw. Embed. Syst. , vol. 2024, no. 1, pp. 457–500, 2024

  30. [30]

    SVF: Interprocedural Static Value-Flow Analysis in LLVM,

    Y . Sui and J. Xue, “SVF: Interprocedural Static Value-Flow Analysis in LLVM,” in 25th International Conference on Compiler Construction (CC), A. Zaks and M. V . Hermenegildo, Eds. ACM, 2016

  31. [31]

    Augury: Using Data Memory-Dependent Prefetchers to Leak Data at Rest,

    J. R. S. Vicarte, M. Flanders, R. Paccagnella, G. Garrett-Grossman, A. Morrison, C. W. Fletcher, and D. Kohlbrenner, “Augury: Using Data Memory-Dependent Prefetchers to Leak Data at Rest,” in 2022 IEEE Symposium on Security and Privacy (S&P) . IEEE, 2022, pp. 1491– 1505

  32. [32]

    Opening Pandora’s Box: A Systematic Study of New Ways Microarchitecture Can Leak Private Data,

    J. R. S. Vicarte, P. Shome, N. Nayak, C. Trippel, A. Morrison, D. Kohlbrenner, and C. W. Fletcher, “Opening Pandora’s Box: A Systematic Study of New Ways Microarchitecture Can Leak Private Data,” in48th ACM/IEEE Annual International Symposium on Computer Architecture (ISCA). IEEE, 2021, pp. 347–360

  33. [33]

    Further Scramblings of Marsaglia’s Xorshift Generators,

    S. Vigna, “Further Scramblings of Marsaglia’s Xorshift Generators,” J. Comput. Appl. Math. , vol. 315, pp. 175–181, 2017

  34. [34]

    Peek-a-Walk: Leaking Secrets via Page Walk Side Channels,

    A. Wang, B. Chen, Y . Wang, C. Fletcher, D. Genkin, D. Kohlbrenner, and R. Paccagnella, “Peek-a-Walk: Leaking Secrets via Page Walk Side Channels,” in 2025 IEEE Symposium on Security and Privacy (S&P) . IEEE, 2025. [Online]. Available: https://www.computer.org/csdl/procee dings-article/sp/2025/223600a023/21B7QepK7Fm

  35. [35]

    The RISC-V Instruction Set Manual, V olume I: Unprivileged ISA (Document Version 20191213)

    A. Waterman and K. Asanovic, “The RISC-V Instruction Set Manual, V olume I: Unprivileged ISA (Document Version 20191213).” [Online]. Available: https://riscv.org/wp-content/uploads/2019/12/riscv-spec-201 91213.pdf

  36. [36]

    Cipherfix: Mitigating Ciphertext Side-Channel Attacks in Software (Slides)

    J. Wichelmann and A. P ¨atschke, “Cipherfix: Mitigating Ciphertext Side-Channel Attacks in Software (Slides).” [Online]. Available: https://www.usenix.org/system/files/sec23 slides wichelmann.pdf

  37. [37]

    Cipherfix: Mitigating Ciphertext Side-Channel Attacks in Software,

    J. Wichelmann, A. P ¨atschke, L. Wilke, and T. Eisenbarth, “Cipherfix: Mitigating Ciphertext Side-Channel Attacks in Software,” in 32nd USENIX Security Symposium , J. A. Calandrino and C. Troncoso, Eds. USENIX Association, 2023. [Online]. Available: https://www.usenix.o rg/conference/usenixsecurity23/presentation/wichelmann

  38. [38]

    Obelix: Mitigating Side-Channels through Dynamic Obfuscation,

    J. Wichelmann, A. Rabich, A. P ¨atschke, and T. Eisenbarth, “Obelix: Mitigating Side-Channels through Dynamic Obfuscation,” in 2024 IEEE Symposium on Security and Privacy (S&P) . IEEE, 2024

  39. [39]

    Microwalk-CI: Practical Side-Channel Analysis for JavaScript Applications,

    J. Wichelmann, F. Sieck, A. P ¨atschke, and T. Eisenbarth, “Microwalk-CI: Practical Side-Channel Analysis for JavaScript Applications,” in 2022 ACM SIGSAC Conference on Computer and Communications Security (CCS), H. Yin, A. Stavrou, C. Cremers, and E. Shi, Eds. ACM, 2022, pp. 2915–2929

  40. [40]

    Architectural Mimicry: Innovative Instructions to Efficiently Address Control-Flow Leakage in Data-Oblivious Programs,

    H. Winderix, M. Bognar, J. Noorman, L.-A. Daniel, and F. Piessens, “Architectural Mimicry: Innovative Instructions to Efficiently Address Control-Flow Leakage in Data-Oblivious Programs,” in 2024 IEEE Symposium on Security and Privacy (S&P) . IEEE, 2024. [Online]. Available: https://doi.ieeecomputersociety.org/10.1109/SP54263.2024.0 0047

  41. [41]

    Compiler-Assisted Hard- ening of Embedded Software Against Interrupt Latency Side-Channel Attacks,

    H. Winderix, J. T. M ¨uhlberg, and F. Piessens, “Compiler-Assisted Hard- ening of Embedded Software Against Interrupt Latency Side-Channel Attacks,” in 2021 IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, 2021, pp. 667–682

  42. [42]

    Ciphertext Side-Channel Patches

    WolfSSL, “Ciphertext Side-Channel Patches.” [Online]. Available: https://github.com/wolfSSL/wolfssl/pull/4666 APPENDIX A DATA MEMORY-D EPENDENT PREFETCHERS Apart from the previously discussed leakages originating from ciphertext side-channels and silent stores, data memory- dependent prefetchers (DMPs) also fall into the category of memory-centric side-ch...