arxiv: 2605.10049 · v1 · submitted 2026-05-11 · 💻 cs.CR

Recognition: 2 theorem links

· Lean Theorem

Janus: Compiler-Based Defense Against Transient Execution Attacks Using ARM Hardware Primitives

Ciyan Ouyang, Dan Meng, Peinan Li, Rui Hou, Yubiao Huang

Authors on Pith no claims yet

Pith reviewed 2026-05-12 02:28 UTC · model grok-4.3

classification 💻 cs.CR

keywords compiler-based defensetransient execution attacksSpectreARM64pointer authenticationbranch target identificationcontrol flow integrityperformance overhead

0 comments

The pith

Janus uses ARM pointer authentication and branch target identification in a compiler to block Spectre-style transient execution attacks while keeping overhead under 4 percent on average.

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

The paper presents Janus as a compiler framework that instruments ARM64 code to tie speculative execution paths and control-flow dependencies to hardware PA modifiers. This extends existing control-flow integrity mechanisms so they also cover transient execution, preventing attacks that rely on mispredicted branches or speculative control-flow hijacking. Optimizations merge defense operations across layers and reuse registers to hold protected values, keeping the added cost low. If the approach works, ARM platforms gain protection against Spectre-class exploits without new hardware or heavy runtime checks. The evaluation on SPEC CPU2017 reports 3.85 percent average slowdown, with real applications between roughly 3 and 8 percent.

Core claim

Janus integrates speculative execution and control flow dependencies with PA modifiers, using PA and BTI microarchitectural features to prevent control-flow speculation attacks and secure both control flow and speculative execution through existing control-flow integrity mechanisms, while applying modifier fusion and carrier reuse to limit performance and code-size costs.

What carries the argument

Compiler instrumentation that merges PA modifiers across speculative and non-speculative paths and reuses registers to carry protected values, extending ARM's existing PA/BTI CFI primitives to cover transient execution.

If this is right

Existing ARM control-flow integrity hardware can be reused to protect against transient-execution attacks rather than requiring separate mitigations.
Modifier fusion and register reuse keep the defense overhead low enough for production use on SPEC workloads and typical applications.
Both control-flow hijacking and speculative leakage are addressed by the same instrumentation pass.
The defense applies at compile time and therefore scales to entire codebases without runtime binary rewriting.

Where Pith is reading between the lines

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

Similar compiler passes could be developed for other ISAs that expose comparable pointer-authentication or branch-target primitives.
The technique might combine with hardware speculation barriers for defense-in-depth without doubling the cost.
If the static analysis misses rare paths, dynamic feedback or profiling could be added later to close remaining gaps.

Load-bearing premise

A compiler can statically identify and instrument every possible speculative execution path and control-flow dependency so that the added PA and BTI checks leave no gaps an attacker could exploit.

What would settle it

An end-to-end Spectre-style exploit that succeeds on Janus-protected ARM64 binaries, either by bypassing the inserted modifiers or by using an uninstrumented speculation path.

Figures

Figures reproduced from arXiv: 2605.10049 by Ciyan Ouyang, Dan Meng, Peinan Li, Rui Hou, Yubiao Huang.

**Figure 2.** Figure 2: The architecture of the Janus compiler framework, detailing the pipeline of analysis, transformation, and instrumen [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** Figure 3: Janus Defense Mechanisms [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗

**Figure 4.** Figure 4: Vulnerable C Code Snippet. .bb2:initialize_uid mov w0, w1 ret true .bb3:root_request cmp w0, #0 b.ne user_path .bb5:user_path //....user path code .... .bb6:root_request ldr x4, [handlers, x3, lsl #3] blr x4 .bb8:root_request // ... (function epilogue) ... ret .bb4:admin_path ldrb w2, [pdata, x1] lsl x2, x2, #12 strb wzr, [varray, x2] b .L_continue .bb1:root_request ...... bl initialize_uid false .bb7:h_a… view at source ↗

**Figure 7.** Figure 7: SPEC CPU 2017 performance results. 7 Evaluation 7.1 Experimental Setup We use a unified strategy for performance and security evaluation on the Radxa Orion O6 development board with 16 GB of DDR5 memory, featuring an ARM Cortex-A720 CPU with 4 big cores at 2.8 GHz, 4 medium cores at 2.4 GHz, and 4 little cores at 1.8 GHz, running Ubuntu 24 (Kernel 6.11) with LLVM/Clang 20.1 (+LTO, -O3). For consistency, we… view at source ↗

**Figure 8.** Figure 8: Code-size increase for Janus. 7.3 Security Evaluation CFI and DFI: Janus defends against Spectre attacks by leveraging external CFI/DFI analysis results and using basic non-control data protection (conditional variables) for testing. It passed all ConFIRM tests except JIT and effectively protected against string buffer attacks on conditional branch variables. Traditional Spectre Attacks: To evaluate Janu… view at source ↗

read the original abstract

We present Janus, a compiler-based security framework that mitigates transient execution attacks like Spectre and control-flow hijacking on ARM64 platforms. Janus integrates speculative execution and control flow dependencies with PA modifiers, using PA and BTI microarchitectural features to prevent control-flow speculation attacks and secure both control flow and speculative execution through existing control-flow integrity mechanisms. To optimize performance, Janus minimizes overhead by merging defense operations across different defense layers (modifier fusion) and reusing registers of protected variables (carrier reuse), while maintaining strong security guarantees. Evaluation on SPEC CPU2017 shows an average performance overhead of 3.85%, with real-world applications exhibiting overheads ranging from 2.97% to 7.80%. Janus offers effective speculative execution security and low performance and code size overhead, making it a robust solution for ARM-based systems.

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.

Desk Editor's Note private letter to a colleague

Janus is a practical compiler pass that fuses ARM PA and BTI into one instrumentation layer for Spectre and CFI defense, with optimizations that keep overhead low, but the security claim still rests on how completely static analysis can track speculative paths.

read the letter

Janus layers ARM Pointer Authentication and Branch Target Identification into a compiler to protect against both transient execution attacks like Spectre and ordinary control-flow hijacks. The engineering move is to treat speculative execution dependencies and control-flow edges together under the same PA modifiers, then apply BTI to constrain speculation targets. Modifier fusion and carrier reuse are the concrete optimizations that cut the cost of doing both at once. The reported numbers are the clearest positive: 3.85% average on SPEC CPU2017 and 2.97–7.80% on real applications, which is low enough to be usable on ARM platforms. That combination of joint protection plus measured overhead is the part that feels new relative to prior separate CFI or Spectre-mitigation passes. The soft spot is exactly the one the stress-test note flags. The whole guarantee depends on the compiler statically identifying every control-flow dependency and every speculative execution path so that the inserted PA checks and BTI labels close the channels. Static analysis is incomplete for data-dependent indirect branches, aliasing, and cross-function speculation, and the fusion/reuse steps add more places where a missed site could appear. The abstract gives no formal model, no gadget coverage numbers, and no proof that the instrumentation itself does not create new transient gadgets. If the full paper has exhaustive testing or a precise description of what the analysis actually covers, that would change the picture; from the given text the coverage claim stays empirical rather than rigorous. This is for systems-security people and compiler writers who need a low-overhead ARM-specific defense and are willing to accept the limits of static tracking. It has enough implementation detail and performance data to deserve a serious referee, though the review should focus on analysis precision and attack coverage. I would send it out for review.

Referee Report

3 major / 2 minor

Summary. The paper presents Janus, a compiler-based framework for ARM64 that mitigates transient execution attacks (Spectre-style) and control-flow hijacking by integrating speculative execution and control-flow dependencies with Pointer Authentication (PA) modifiers. It leverages existing PA and Branch Target Identification (BTI) microarchitectural features to enforce control-flow integrity on both committed and transient paths. Optimizations include modifier fusion across defense layers and carrier reuse of registers for protected variables. Evaluation reports 3.85% average overhead on SPEC CPU2017 and 2.97–7.80% on real-world applications, claiming strong security with low performance and code-size cost.

Significance. If the security guarantees hold, the work is significant for providing a practical, low-overhead defense on ARM platforms that reuses existing hardware CFI primitives rather than requiring new instructions or microarchitectural changes. The empirical results on standard benchmarks and the focus on compiler integration of speculation tracking with PA/BTI are strengths that could influence secure compilation practices.

major comments (3)

[Abstract and §5] Abstract and §5 (Evaluation): The reported performance numbers (3.85% SPEC average) are given without accompanying data on attack coverage, residual gadget count, or threat-model completeness. This is load-bearing because the central claim is that PA/BTI enforcement plus compiler tracking closes all transient channels; without coverage metrics or gadget enumeration, the security result cannot be assessed.
[§3 and §4] §3 (Design) and §4 (Implementation): The description of compile-time tracking of speculative execution paths and control-flow dependencies does not address completeness for data-dependent indirect branches, aliasing, or cross-function speculation. The optimizations (modifier fusion, carrier reuse) are presented as preserving guarantees, but no argument or static analysis is supplied showing they do not introduce new transient gadgets or leave sites uninstrumented.
[§3.1–3.3] §3.1–3.3: No formal model of the instrumentation semantics or proof that the PA modifier placement plus BTI enforcement is sufficient to block all control-flow speculation attacks is provided. The security argument therefore rests entirely on the unverified assumption that static analysis can identify every relevant dependency.

minor comments (2)

[Abstract] The abstract claims 'strong security guarantees' are maintained by the optimizations; a short paragraph clarifying the threat model (e.g., whether it includes all Spectre variants or only control-flow ones) would improve clarity.
[§5] Table or figure presenting code-size overhead alongside the performance numbers is missing; adding one would make the 'low code size overhead' claim easier to evaluate.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the constructive and detailed feedback. We address each major comment below, indicating revisions where the manuscript will be updated to improve clarity and completeness without altering the core claims.

read point-by-point responses

Referee: [Abstract and §5] Abstract and §5 (Evaluation): The reported performance numbers (3.85% SPEC average) are given without accompanying data on attack coverage, residual gadget count, or threat-model completeness. This is load-bearing because the central claim is that PA/BTI enforcement plus compiler tracking closes all transient channels; without coverage metrics or gadget enumeration, the security result cannot be assessed.

Authors: The evaluation in §5 focuses on performance as the primary quantitative result, while security is argued via the design in §3–4. We will revise §2 to include an explicit threat model and add to §5 a discussion of coverage for common Spectre-style patterns (e.g., bounds-check bypass, indirect-branch poisoning) together with a qualitative analysis of residual gadgets after instrumentation. Full per-benchmark gadget enumeration was not performed due to its high computational cost and is noted as a limitation; the quantitative security claim is therefore scoped to the enforcement properties rather than exhaustive enumeration. revision: partial
Referee: [§3 and §4] §3 (Design) and §4 (Implementation): The description of compile-time tracking of speculative execution paths and control-flow dependencies does not address completeness for data-dependent indirect branches, aliasing, or cross-function speculation. The optimizations (modifier fusion, carrier reuse) are presented as preserving guarantees, but no argument or static analysis is supplied showing they do not introduce new transient gadgets or leave sites uninstrumented.

Authors: The tracking pass in §4 builds on LLVM’s existing control-flow and alias analyses, conservatively instrumenting all indirect branches and call sites; data-dependent branches are handled by propagating speculation tags through the SSA form. Cross-function speculation is addressed by PA-protected returns and BTI at call targets. Modifier fusion merges only semantically equivalent PA operations, and carrier reuse is restricted to registers already carrying protected values, preserving the authentication invariants. We will add a new subsection in §4.3 that states the soundness assumptions of the analysis and provides a short argument, with examples, that the optimizations do not create new transient control-flow paths. revision: yes
Referee: [§3.1–3.3] §3.1–3.3: No formal model of the instrumentation semantics or proof that the PA modifier placement plus BTI enforcement is sufficient to block all control-flow speculation attacks is provided. The security argument therefore rests entirely on the unverified assumption that static analysis can identify every relevant dependency.

Authors: We provide an informal security argument based on the documented semantics of ARM PA authentication failures and BTI traps, showing that any speculative deviation from the intended control flow will trigger a fault before observable effects. We will expand §3.1–3.3 with a structured proof sketch that enumerates the possible speculation points and demonstrates that each is covered by the inserted checks. A machine-checked formal model lies outside the scope of the current work and would require substantial additional effort; we will note this explicitly as future work. revision: partial

Circularity Check

0 steps flagged

No circularity: engineering system with empirical evaluation only

full rationale

The paper presents an engineering compiler framework (Janus) that instruments code using ARM PA/BTI primitives, with optimizations such as modifier fusion and carrier reuse, followed by SPEC CPU2017 benchmarks reporting 3.85% average overhead. No mathematical derivation chain, equations, fitted parameters, or predictions exist that could reduce to inputs by construction. Security claims rest on the described instrumentation and measured performance rather than self-referential logic or self-citation load-bearing steps. The work is self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The framework assumes standard behavior of ARM PA and BTI hardware primitives and that compile-time analysis can correctly identify all relevant speculative and control-flow dependencies without runtime gaps.

axioms (2)

domain assumption ARM PA and BTI hardware primitives enforce the intended control-flow and pointer integrity properties when used as described.
Invoked when the abstract states that PA and BTI are used to prevent control-flow speculation attacks.
domain assumption The compiler's static analysis of speculative execution and control-flow dependencies is complete and sound for the targeted attack classes.
Required for the claim that the integration secures both control flow and speculative execution.

pith-pipeline@v0.9.0 · 5472 in / 1356 out tokens · 38545 ms · 2026-05-12T02:28:37.686453+00:00 · methodology

discussion (0)

Lean theorems connected to this paper

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

IndisputableMonolith/Foundation/RealityFromDistinction.lean reality_from_one_distinction unclear
Janus integrates speculative execution and control flow dependencies with PA modifiers, using PA and BTI microarchitectural features to prevent control-flow speculation attacks
IndisputableMonolith/Cost/FunctionalEquation.lean washburn_uniqueness_aczel unclear
modifier fusion ... reusing registers of protected variables (carrier reuse)

Reference graph

Works this paper leans on

36 extracted references · 36 canonical work pages

[1]

Enrico Barberis, Pietro Frigo, Marius Muench, Herbert Bos, and Cristiano Giuf- frida. 2022. Branch History Injection: On the Effectiveness of Hardware Mit- igations Against Cross-Privilege Spectre-v2 Attacks. In31st USENIX Security Symposium (USENIX Security 22). USENIX Association, Boston, MA, 971–988. https://www.usenix.org/conference/usenixsecurity22/p...

work page 2022
[2]

Markus Bauer, Lorenz Andreas Hetterich, Christian Rossow, and Michael Schwarz

work page
[3]

Switchpoline: A Software Mitigation for Spectre-BTB and Spectre-BHB on ARMv. (2024)

work page 2024
[4]

Tyler Bletsch, Xuxian Jiang, Vince W Freeh, and Zhenkai Liang. 2011. Jump- oriented programming: a new class of code-reuse attack. InProceedings of the 6th ACM symposium on information, computer and communications security. 30–40

work page 2011
[5]

Nathan Burow, Scott A Carr, Joseph Nash, Per Larsen, Michael Franz, Stefan Brunthaler, and Mathias Payer. 2017. Control-flow integrity: Precision, security, and performance.ACM Computing Surveys (CSUR)50, 1 (2017), 1–33

work page 2017
[6]

Nicholas Carlini, Antonio Barresi, Mathias Payer, David Wagner, and Thomas R Gross. 2015. Control-flow bending: On the effectiveness of control-flow integrity. In24th USENIX Security Symposium (USENIX Security 15). 161–176

work page 2015
[7]

2024.Speculative Load Hardening

Chandler Carruth. 2024.Speculative Load Hardening. Technical Report

work page 2024
[8]

Miguel Castro, Manuel Costa, and Tim Harris. 2006. Securing software by enforcing data-flow integrity. InProceedings of the 7th symposium on Operating systems design and implementation. 147–160

work page 2006
[9]

Xiangdong Chen, Zhaofeng Li, Tirth Jain, Vikram Narayanan, and Anton Burtsev

work page
[10]

In2024 USENIX Annual Technical Conference (USENIX ATC 24)

Limitations and opportunities of modern hardware isolation mechanisms. In2024 USENIX Annual Technical Conference (USENIX ATC 24). 349–368

work page
[11]

Neophytos Christou, Alexander J Gaidis, Vaggelis Atlidakis, and Vasileios P Ke- merlis. 2024. Eclipse: Preventing Speculative Memory-error Abuse with Artificial Data Dependencies. InProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security. 3913–3927

work page 2024
[12]

Crispin Cowan, Perry Wagle, Calton Pu, Steve Beattie, and Jonathan Walpole

work page
[13]

InProceedings of the DARPA Information Survivability Conference & Exposition

Buffer overflows: Attacks and defenses for the vulnerability of the decade. InProceedings of the DARPA Information Survivability Conference & Exposition. IEEE, 119–129

work page
[14]

Luís Fiolhais and Leonel Sousa. 2023. Transient-Execution Attacks: A Com- puter Architect Perspective.Comput. Surveys56 (2023), 1 – 38. https: //api.semanticscholar.org/CorpusID:259120377

work page 2023
[15]

Saber Ganjisaffar, Esmaeil Mohmmadian Koruyeh, Jason Zellmer, Hodjat Asghari Esfeden, Chengyu Song, and Nael Abu-Ghazaleh. 2025. SpecASan: Mitigating Transient Execution Attacks Using Speculative Address Sanitization. InProceed- ings of the 52nd Annual International Symposium on Computer Architecture (ISCA ’25). Association for Computing Machinery, New Yo...

work page doi:10.1145/3695053.3731119 2025
[16]

Enes Göktas, Kaveh Razavi, Georgios Portokalidis, Herbert Bos, and Cristiano Giuffrida. 2020. Speculative probing: Hacking blind in the Spectre era. InPro- ceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security. 1871–1885

work page 2020
[17]

Deepak Gupta. 2024. riscv control-flow integrity for usermode. https://lwn.net/ Articles/990220/

work page 2024
[18]

Hong Hu, Shweta Shinde, Sendroiu Adrian, Zheng Leong Chua, Prateek Saxena, and Zhenkai Liang. 2016. Data-oriented programming: On the expressiveness of non-control data attacks. In2016 IEEE Symposium on Security and Privacy (SP). IEEE, 969–986

work page 2016
[19]

2023.IntelAnalysisofSpeculativeExecutionSideChannels

Intel. 2023.IntelAnalysisofSpeculativeExecutionSideChannels. Technical Report. Intel

work page 2023
[20]

Intel Corporation. 2019. Control-flow Enforcement Technology Specification (Revision 3.0). https://kib.kiev.ua/x86docs/Intel/CET/334525-003.pdf

work page 2019
[21]

Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, et al. 2020. Spectre attacks: Exploiting speculative execution.Commun. ACM63, 7 (2020), 93–101

work page 2020
[22]

Khasawneh, Chengyu Song, and Nael B

Esmaeil Mohammadian Koruyeh, Khaled N. Khasawneh, Chengyu Song, and Nael B. Abu-Ghazaleh. 2018. Spectre Returns! Speculation Attacks Using the Re- turn Stack Buffer.IEEE Design & Test41 (2018), 47–55. https://api.semanticscholar. org/CorpusID:49901800

work page 2018
[23]

2022.ARM Architecture Reference Manual ARMv8, for ARMv8-A architec- ture profile

ARM Ltd. 2022.ARM Architecture Reference Manual ARMv8, for ARMv8-A architec- ture profile. ARM Ltd. https://developer.arm.com/documentation/ddi0487/latest

work page 2022
[24]

2023.Arm A -profile Architecture: Feature Description – FEAT_FPAC (Faulting on Pointer Authentication failures)

Arm Ltd. 2023.Arm A -profile Architecture: Feature Description – FEAT_FPAC (Faulting on Pointer Authentication failures). Technical Report. Arm Ltd. Accessed: YYYY-MM-DD

work page 2023
[25]

Tiziano Marinaro, Pablo Buiras, Andreas Lindner, Roberto Guanciale, and Hamed Nemati. 2024. Beyond Over-Protection: A Targeted Approach to Spectre Mit- igation and Performance Optimization. InProceedings of the 19th ACM Asia Conference on Computer and Communications Security. 203–216

work page 2024
[26]

Matt Miller. 2019. Trends and challenges in the vulnerability mitigation landscape. USENIX Association(2019)

work page 2019
[27]

PaX Team. 2003. PaX Address Space Layout Randomization (ASLR). https: //pax.grsecurity.net/docs/aslr.txt

work page 2003
[28]

Kemerlis

Marios Pomonis, Theofilos Petsios, Angelos Dennis Keromytis, Michalis Poly- chronakis, and Vasileios P. Kemerlis. 2017. 𝑘𝑅 𝑋 : Comprehensive Kernel Protec- tion against Just-In-Time Code Reuse.Proceedings of the Twelfth European Con- ference on Computer Systems(2017). https://api.semanticscholar.org/CorpusID: 592404

work page 2017
[29]

Joseph Ravichandran, Weon Taek Na, Jay Lang, and Mengjia Yan. 2022. PACMAN: attacking ARM pointer authentication with speculative execution. InProceedings of the 49th Annual International Symposium on Computer Architecture. 685–698

work page 2022
[30]

Ryan Roemer, Erik Buchanan, Hovav Shacham, and Stefan Savage. 2012. Return- oriented programming: Systems, languages, and applications.ACM Transactions on Information and System Security (TISSEC)15, 1 (2012), 1–34

work page 2012
[31]

Marc Schink and Johannes Obermaier. 2019. Taking a Look into Execute-Only Memory.ArXivabs/1909.05771 (2019). https://api.semanticscholar.org/CorpusID: 201803787

work page arXiv 2019
[32]

Felix Schuster, Thomas Tendyck, Christopher Liebchen, Lucas Davi, Ahmad-Reza Sadeghi, and Thorsten Holz. 2015. Counterfeit object-oriented programming: On the difficulty of preventing code reuse attacks in C++ applications. In2015 IEEE Symposium on Security and Privacy. IEEE, 745–762

work page 2015
[33]

Armanuzzaman, Zheyuan Ma, Gaoxiang Liu, Alex Eastman, Hongxin Hu, and Ziming Zhao

Xi Tan, Sagar Mohan, Md. Armanuzzaman, Zheyuan Ma, Gaoxiang Liu, Alex Eastman, Hongxin Hu, and Ziming Zhao. 2024. Is the Canary Dead? On the Effectiveness of Stack Canaries on Microcontroller Systems.Proceedings of the 39th ACM/SIGAPP Symposium on Applied Computing(2024). https://api. semanticscholar.org/CorpusID:269951615

work page 2024
[34]

Marco Vassena, Craig Disselkoen, Klaus von Gleissenthall, Sunjay Cauligi, Rami Gökhan Kıcı, Ranjit Jhala, Dean Tullsen, and Deian Stefan. 2021. Au- tomatically eliminating speculative leaks from cryptographic code with blade. Proceedings of the ACM on Programming Languages5, POPL (2021), 1–30

work page 2021
[35]

Sander Wiebing, Alvise de Faveri Tron, Herbert Bos, and Cristiano Giuffrida. 2024. {InSpectre} Gadget: Inspecting the Residual Attack Surface of Cross-privilege Spectre v2. In33rd USENIX Security Symposium (USENIX Security 24). 577–594

work page 2024
[36]

Wenjie Xiong and Jakub Szefer. 2021. Survey of Transient Execution Attacks and Their Mitigations.ACM Computing Surveys (CSUR)54 (2021), 1 – 36. https: //api.semanticscholar.org/CorpusID:235348755

work page 2021