pith. sign in

arxiv: 2605.00613 · v2 · submitted 2026-05-01 · 💻 cs.CR

KingsGuard: Enclave Data Protection Under Real-World TEE Vulnerabilities

Pith reviewed 2026-05-09 19:27 UTC · model grok-4.3

classification 💻 cs.CR
keywords Trusted Execution EnvironmentsEnclave SecurityData Flow TrackingHardware SecurityData Leak PreventionRISC-V ProcessorTEE VulnerabilitiesControlled Declassification
0
0 comments X

The pith

KingsGuard adds hardware data flow tracking inside TEE enclaves to block leaks even when code or hardware is vulnerable.

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

The paper proposes KingsGuard as a TEE design that uses hardware to track how sensitive data moves inside an enclave and stops it from escaping. This targets the real problem that enclave code bugs and hardware flaws can create leak paths despite the isolation promises of TEEs. The design adds fine-grained checks plus a controlled way to release data intentionally when needed. A RISC-V prototype shows the changes fit with about 11 percent extra hardware area and under 6 percent slowdown. If the tracking works as described, enclaves could handle sensitive work more safely without assuming perfect software or hardware.

Core claim

KingsGuard is a TEE design that systematically monitors and controls the propagation of sensitive data within an enclave by enforcing fine-grained data flow tracking and checks in hardware. This ensures sensitive data does not leave the enclave boundary and thereby bridges the gap between idealized TEE threat models and practical realizations with vulnerabilities in code or hardware. The approach includes controlled declassification at enclave boundaries to permit intentional release of data to the outside world when required.

What carries the argument

KingsGuard's hardware data flow tracking and enforcement mechanism, which identifies sensitive sources and blocks unauthorized propagation paths while permitting controlled declassification.

If this is right

  • Enclave computations stay protected against leaks even if the enclave code contains bugs or the underlying hardware has flaws.
  • Enclaves can still send required outputs to untrusted software through the controlled declassification points.
  • The security guarantees of TEEs become closer to their theoretical model without requiring flawless isolation in every layer.
  • Practical deployment remains feasible because the measured hardware area and performance overheads stay modest on RISC-V.
  • Sensitive applications such as key management or private data processing can run inside enclaves with reduced risk of accidental exposure.

Where Pith is reading between the lines

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

  • The same hardware tracking idea could be adapted to other instruction sets or existing commercial TEEs to strengthen them against known attacks.
  • If the mechanism scales, it might reduce the need for extensive software audits of enclave code in cloud environments.
  • Longer term, combining this hardware layer with existing software defenses could create defense-in-depth for highly regulated data.
  • Empirical testing against published TEE side-channel and code-injection attacks on the prototype would provide direct evidence of its coverage.

Load-bearing premise

The added hardware can correctly identify and block all possible data propagation paths from sensitive sources without missing leaks or introducing new side channels, while the declassification mechanism stays secure under attack.

What would settle it

A working demonstration that extracts sensitive data from a KingsGuard-protected enclave on the RISC-V implementation, either by exploiting an untracked leak path or by attacking the declassification controls.

Figures

Figures reproduced from arXiv: 2605.00613 by Chester Rebeiro, Deepanjali S, Devashish Gosain, Rohit Srinivas R G, Saltanat Firdous Allaqband.

Figure 1
Figure 1. Figure 1: KINGSGUARD prevents enclave data leakage through three enforcement points: (1) checking taints at the enclave boundary to stop direct leakage into untrusted memory, (2) tracking whether sensitive values influence non-enclave ad￾dresses to block indirect leakage, (3) stamping shared regis￾ters to prevent unauthorized reads from outside the enclave. continuously monitors the flow of sensitive information dur… view at source ↗
Figure 2
Figure 2. Figure 2: An enclave code snippet with its corresponding view at source ↗
Figure 3
Figure 3. Figure 3: Taints 𝑇 ∗ and hashes 𝐻 ∗ added to the binary. taint_buf hash_buf 64-bit 1-bit SM managed secure memory Shadow Memory RAM accessible to all software components view at source ↗
Figure 6
Figure 6. Figure 6: Non-enclave components are not allowed to access view at source ↗
Figure 4
Figure 4. Figure 4: The taints extracted from the enclave binary view at source ↗
Figure 7
Figure 7. Figure 7: Output registers are tainted with the conservative view at source ↗
Figure 8
Figure 8. Figure 8: Interaction between enclave and non-enclave com view at source ↗
Figure 9
Figure 9. Figure 9: Handling of asynchronous interrupt in an enclave. view at source ↗
Figure 10
Figure 10. Figure 10: Percentage overheads of KINGSGUARD implemented as a 1) Baseline TEE, 2) TEE with Information Flow Tracking, 3) TEE with Information Flow Tracking and Declassification evaluated using Embench [39]. KINGSGUARD’s: Baseline TEE TEE + IFT TEE + IFT + Declassification (a) L1 Data Cache: 16 KB, L2 Cache: 128 KB (b) L1 Data Cache: 32 KB, L2 Cache: 256 KB (c) L1 Data Cache: 64 KB, L2 Cache: 256 KB (d) L1 Data Cach… view at source ↗
Figure 11
Figure 11. Figure 11: Performance overheads of KINGSGUARD for different cache sizes using MiBench [27]. around 0.46% overhead on average. IFT introduces an additional 2.33% overhead, while declassification adds a minimal overhead of 0.09%. Except for mont64, most Embench benchmarks exhibit low IFT overhead. This is because mont64 performs significantly higher percentage of memory accesses than the other workloads. While IFT in… view at source ↗
Figure 12
Figure 12. Figure 12: Percentage overheads of KINGSGUARD over the base￾line processor with and without SassCache countermeasure. AV4: Data leakage in TEEs may also occur through shared peripher￾als. For example, a shared SPI bus in TrustZone allows one applica￾tion to read data from another application’s SPI connection [41]. A code snippet is shown in Listing 4(Top). In KINGSGUARD, all device drivers operate outside the enclav… view at source ↗
read the original abstract

Trusted Execution Environments (TEEs) have emerged as a cornerstone for securing sensitive computations by providing isolated enclaves protected from untrusted software. However, their security guarantees are undermined by vulnerabilities in both the enclave code and the underlying hardware design, which can allow sensitive data to leak despite strong isolation guarantees. This paper presents KINGSGUARD, a novel TEE design that systematically monitors and controls the propagation of sensitive data within an enclave. By enforcing fine-grained data flow tracking and checks in hardware, our approach ensures that sensitive data does not leave the enclave boundary, thus bridging the gap between the idealized threat models of TEEs and their practical realizations. Additionally, to balance security with practical functionality, we introduce controlled declassification at enclave boundaries, allowing intentional release of data to the outside world. Our implementation of KINGSGUARD on a RISC-V processor has a 10.8% hardware area overhead when synthesized on FPGA and a 5.69% performance overhead.

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

3 major / 2 minor

Summary. The manuscript proposes KingsGuard, a TEE design that augments standard enclave isolation with hardware-enforced fine-grained data-flow tracking and boundary checks to prevent sensitive data from leaking out of the enclave, even under vulnerabilities in enclave code or hardware. It introduces a controlled declassification mechanism to permit intentional data release while maintaining security. A RISC-V FPGA implementation is reported to incur 10.8% area overhead and 5.69% performance overhead.

Significance. If the data-flow tracking mechanism can be shown to be complete against all leakage paths (including implicit flows and microarchitectural channels), the approach would meaningfully narrow the gap between idealized TEE threat models and real-world attacks. The modest reported overheads indicate practical deployability on RISC-V platforms. However, the current lack of a formal model, completeness argument, or attack evaluation leaves the central security claim without visible supporting evidence.

major comments (3)
  1. Abstract and §3 (design): the central claim that 'fine-grained data flow tracking and checks in hardware' ensures sensitive data does not leave the enclave boundary is load-bearing, yet no formal model of the taint propagation rules, no argument for completeness against implicit flows or control dependencies, and no counter-example search against known TEE attack vectors (e.g., cache timing, speculative execution) are provided. Without these, the security guarantee cannot be assessed.
  2. §4 (implementation) and evaluation: the reported 10.8% area and 5.69% performance overheads are presented as concrete measurements, but the manuscript supplies no description of the taint-label storage mechanism, the granularity of tracking (register vs. memory word vs. cache line), or how boundary checks are enforced at the enclave exit points. These details are required to reproduce or validate the overhead figures and to confirm they do not introduce new side channels.
  3. §5 (evaluation): no attack evaluation or red-team analysis is described. The weakest assumption—that the added hardware correctly identifies and blocks every propagation path without missing leaks or creating new channels—remains untested against realistic TEE exploits. A single counter-example would falsify the claim.
minor comments (2)
  1. The abstract uses the phrase 'systematically monitors and controls the propagation of sensitive data' without defining the sensitivity labeling policy or the declassification rules; these should be stated explicitly in the design section.
  2. No comparison table is provided against prior hardware taint-tracking or enclave-protection proposals (e.g., Intel TDX, ARM CCA, or academic works on information-flow TEEs); adding one would clarify the novelty of the controlled-declassification feature.

Simulated Author's Rebuttal

3 responses · 1 unresolved

We thank the referee for the thorough and constructive review. The comments highlight important areas where the security arguments and implementation details can be strengthened. We address each major comment below, indicating where we will revise the manuscript and where we provide clarification based on the existing content.

read point-by-point responses
  1. Referee: Abstract and §3 (design): the central claim that 'fine-grained data flow tracking and checks in hardware' ensures sensitive data does not leave the enclave boundary is load-bearing, yet no formal model of the taint propagation rules, no argument for completeness against implicit flows or control dependencies, and no counter-example search against known TEE attack vectors (e.g., cache timing, speculative execution) are provided. Without these, the security guarantee cannot be assessed.

    Authors: We agree that a formal model and completeness argument would strengthen the central claim. The design in §3 specifies explicit taint propagation rules for data movement instructions, register-to-memory transfers, and boundary checks at enclave exits, with controlled declassification via explicit instructions. However, the manuscript does not include a formal semantics or proof of completeness against implicit flows (e.g., control dependencies) or microarchitectural channels. We will add an expanded discussion in §3 on the threat model assumptions, informal arguments for mitigation of common implicit flows through hardware-enforced checks, and references to related hardware taint-tracking literature. A full formal model is beyond the current scope but will be noted as future work. revision: partial

  2. Referee: §4 (implementation) and evaluation: the reported 10.8% area and 5.69% performance overheads are presented as concrete measurements, but the manuscript supplies no description of the taint-label storage mechanism, the granularity of tracking (register vs. memory word vs. cache line), or how boundary checks are enforced at the enclave exit points. These details are required to reproduce or validate the overhead figures and to confirm they do not introduce new side channels.

    Authors: We acknowledge the need for these details to support reproducibility. Section 4 describes the RISC-V FPGA implementation but omits explicit discussion of label storage and enforcement mechanics. We will revise §4 to include: (1) per-register and per-word memory taint label storage using shadow registers and extended memory tags; (2) word-level granularity for tracking; and (3) enforcement of boundary checks via modified enclave exit instructions that consult the hardware taint monitor. Additional synthesis details and discussion of potential new channels (e.g., label storage access patterns) will be added to allow validation of the reported overheads. revision: yes

  3. Referee: §5 (evaluation): no attack evaluation or red-team analysis is described. The weakest assumption—that the added hardware correctly identifies and blocks every propagation path without missing leaks or creating new channels—remains untested against realistic TEE exploits. A single counter-example would falsify the claim.

    Authors: We agree that attack evaluation would provide stronger evidence. The current §5 focuses on performance and area measurements using standard benchmarks. We will add a new subsection to §5 that analyzes representative TEE attack vectors (e.g., data leakage via memory corruption or control-flow hijacking) and explains how KingsGuard's tracking and checks block them. We will also include a brief case study of one known vulnerability class. A comprehensive red-team evaluation against all microarchitectural channels is resource-intensive and will be identified as future work, but the added analysis will address the core concern. revision: partial

standing simulated objections not resolved
  • A complete formal proof of security against all implicit flows and microarchitectural side channels would require a separate, substantial research effort and is not feasible within the revision timeline.

Circularity Check

0 steps flagged

No circularity in the derivation chain

full rationale

The paper describes a hardware TEE design with data-flow tracking and controlled declassification, supported by direct FPGA synthesis measurements (10.8% area, 5.69% performance overhead) rather than any mathematical derivations or predictions. No equations, fitted parameters, self-citations, or ansatzes appear in the provided text; the central claim is a design proposal whose security properties are asserted by construction of the added hardware mechanisms, with no reduction of outputs back to inputs by definition. This matches the reader's assessment of no equations or derived results.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The security guarantee rests on the unproven assumption that hardware can track all data flows without omission; no free parameters or new entities are described in the abstract.

axioms (1)
  • domain assumption Hardware implementation of fine-grained data flow tracking can identify and block all unauthorized propagation paths from sensitive data.
    Invoked to support the claim that sensitive data will not leave the enclave boundary.

pith-pipeline@v0.9.0 · 5486 in / 1149 out tokens · 32443 ms · 2026-05-09T19:27:33.828472+00:00 · methodology

discussion (0)

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

Reference graph

Works this paper leans on

65 extracted references · 65 canonical work pages

  1. [1]

    CVE-2017-6296: NVIDIA TrustZone TOCTOU Vulnerability in DRM Appli- cation

    2017. CVE-2017-6296: NVIDIA TrustZone TOCTOU Vulnerability in DRM Appli- cation. https://nvd.nist.gov/vuln/detail/CVE-2017-6296. Accessed: 2025-10-03

  2. [2]

    Saltanat Firdous Allaqband, Asutosh Brahma, Arjun Menon, Chester Rebeiro, et al. 2025. TESLA: Trusted Execution Support for Legacy Embedded Applications. IACR Transactions on Cryptographic Hardware and Embedded Systems2025, 4 (2025), 899–924

  3. [3]

    Abu-Ghazaleh, and Dmitry Ponomarev

    Kerem Arikan, Abraham Farrell, Williams Zhang Cen, Jack McMahon, Barry Williams, Yu David Liu, Nael B. Abu-Ghazaleh, and Dmitry Ponomarev. 2024. TEE- SHirT: Scalable Leakage-Free Cache Hierarchies for TEEs. In31st Annual Network and Distributed System Security Symposium, NDSS 2024, San Diego, California, USA, February 26 - March 1, 2024. The Internet Soci...

  4. [4]

    Arm Ltd. 2021. Arm Confidential Compute Architecture. https://www.arm. com/architecture/security-features/arm-confidential-compute-architecture. Ac- cessed: 2025

  5. [5]

    Raad Bahmani, Ferdinand Brasser, Ghada Dessouky, Patrick Jauernig, Matthias Klimmek, Ahmad-Reza Sadeghi, and Emmanuel Stapf. 2021. CURE: A Security Architecture with CUstomizable and Resilient Enclaves. In30th USENIX Security Symposium, USENIX Security 2021, August 11-13, 2021, Michael D. Bailey and Rachel Greenstadt (Eds.). USENIX Association, 1073–1090....

  6. [6]

    Gal Beniamini. 2015. Android linux kernel privilege escalation vulnerability and exploit (CVE-2014-4322). http://bits-please.blogspot.com/2015/08/android-linux- kernel-privilege.html. [Online; accessed 5-March-2025]

  7. [7]

    2015.Full TrustZone exploit for MSM8974

    Gal Beniamini. 2015.Full TrustZone exploit for MSM8974. http://bits-please. blogspot.com/2015/08/full-trustzone-exploit-for-msm8974.html

  8. [8]

    Available: https://doi.org/10.1145/2024716.2024718

    Nathan L. Binkert, Bradford M. Beckmann, Gabriel Black, Steven K. Reinhardt, Ali G. Saidi, Arkaprava Basu, Joel Hestness, Derek Hower, Tushar Krishna, So- mayeh Sardashti, Rathijit Sen, Korey Sewell, Muhammad Shoaib Bin Altaf, Nilay Vaish, Mark D. Hill, and David A. Wood. 2011. The gem5 simulator.SIGARCH Comput. Archit. News39, 2 (2011), 1–7. doi:10.1145/...

  9. [9]

    Andrea Biondo, Mauro Conti, Lucas Davi, Tommaso Frassetto, and Ahmad-Reza Sadeghi. 2018. The Guard’s Dilemma: Efficient Code-Reuse Attacks Against Intel SGX. In27th USENIX Security Symposium, USENIX Security 2018, Baltimore, MD, USA, August 15-17, 2018, William Enck and Adrienne Porter Felt (Eds.). USENIX Association, 1213–1227. https://www.usenix.org/con...

  10. [10]

    Pietro Borrello, Andreas Kogler, Martin Schwarzl, Moritz Lipp, Daniel Gruss, and Michael Schwarz. 2022. ÆPIC Leak: Architecturally Leaking Uninitialized Data from the Microarchitecture. In31st USENIX Security Symposium, USENIX Security 2022, Boston, MA, USA, August 10-12, 2022, Kevin R. B. Butler and Kurt Thomas (Eds.). USENIX Association, 3917–3934. http...

  11. [11]

    Lebedev, Andrew Wright, Sizhuo Zhang, Arvind, and Srinivas Devadas

    Thomas Bourgeat, Ilia A. Lebedev, Andrew Wright, Sizhuo Zhang, Arvind, and Srinivas Devadas. 2019. MI6: Secure Enclaves in a Speculative Out-of-Order Processor. InProceedings of the 52nd Annual IEEE/ACM International Symposium on Microarchitecture, MICRO 2019, Columbus, OH, USA, October 12-16, 2019. ACM, 42–56. doi:10.1145/3352460.3358310

  12. [12]

    Ferdinand Brasser, David Gens, Patrick Jauernig, Ahmad-Reza Sadeghi, and Emmanuel Stapf. 2019. SANCTUARY: ARMing TrustZone with User-space Enclaves. In26th Annual Network and Distributed System Security Symposium, NDSS 2019, San Diego, California, USA, February 24-27, 2019. The Internet Soci- ety. https://www.ndss-symposium.org/ndss-paper/sanctuary-arming...

  13. [13]

    David Cerdeira, José Martins, Nuno Santos, and Sandro Pinto. 2022. ReZone: Disarming TrustZone with TEE privilege reduction. In31st USENIX Security Symposium (USENIX Security 22). 2261–2279

  14. [14]

    Yang Chen, Jianfeng Jiang, Shoumeng Yan, and Hui Xu. 2023. Mind Your Enclave Pointers! Detecting Privacy Leaks for SGX Apps via Sparse Taint Analysis. In2023 IEEE 34th International Symposium on Software Reliability Engineering (ISSRE). 24–35. doi:10.1109/ISSRE59848.2023.00022

  15. [15]

    Tobias Cloosters, Michael Rodler, and Lucas Davi. 2020. TeeRex: Discovery and exploitation of memory corruption vulnerabilities in SGX enclaves. In29th USENIX Security Symposium (USENIX Security 20). 841–858

  16. [16]

    Tobias Cloosters, Johannes Willbold, Thorsten Holz, and Lucas Davi. 2022. SGX- Fuzz: Efficiently synthesizing nested structures for SGX enclave fuzzing. In31st USENIX Security Symposium (USENIX Security 22). 3147–3164

  17. [17]

    2022.Intel®Trust Domain Extensions (Intel®TDX) White Paper

    Intel Corporation. 2022.Intel®Trust Domain Extensions (Intel®TDX) White Paper. Technical Report. Intel. White Paper

  18. [18]

    Victor Costan and Srinivas Devadas. 2016. Intel SGX Explained.IACR Cryptol. ePrint Arch.(2016), 86. http://eprint.iacr.org/2016/086

  19. [19]

    Lebedev, and Srinivas Devadas

    Victor Costan, Ilia A. Lebedev, and Srinivas Devadas. 2016. Sanctum: Minimal Hardware Extensions for Strong Software Isolation. In25th USENIX Security Sym- posium, USENIX Security 16, Austin, TX, USA, August 10-12, 2016, Thorsten Holz and Stefan Savage (Eds.). USENIX Association, 857–874. https://www.usenix. org/conference/usenixsecurity16/technical-sessi...

  20. [20]

    Jinhua Cui, Jason Zhijingcheng Yu, Shweta Shinde, Prateek Saxena, and Zhiping Cai. 2021. Smashex: Smashing SGX enclaves using exceptions. InProceedings of the 2021 ACM SIGSAC conference on computer and communications security. 779–793

  21. [21]

    Ghada Dessouky, Tommaso Frassetto, and Ahmad-Reza Sadeghi. 2020. HybCache: Hybrid Side-Channel-Resilient caches for trusted execution environments. In 29th USENIX Security Symposium (USENIX Security 20). 451–468

  22. [22]

    Leonid Domnitser, Aamer Jaleel, Jason Loew, Nael Abu-Ghazaleh, and Dmitry Ponomarev. 2012. Non-monopolizable caches: Low-complexity mitigation of cache side channel attacks.ACM Transactions on Architecture and Code Optimiza- tion (TACO)8, 4 (2012), 1–21

  23. [23]

    Qian Ge, Yuval Yarom, David Cock, and Gernot Heiser. 2018. A survey of mi- croarchitectural timing attacks and countermeasures on contemporary hardware. Journal of Cryptographic Engineering8, 1 (2018), 1–27

  24. [24]

    Lukas Giner, Stefan Steinegger, Antoon Purnal, Maria Eichlseder, Thomas Unter- luggauer, Stefan Mangard, and Daniel Gruss. 2023. Scatter and Split Securely: Defeating Cache Contention and Occupancy Attacks. In44th IEEE Symposium on Security and Privacy, SP 2023, San Francisco, CA, USA, May 21-25, 2023. IEEE, 2273–2287. doi:10.1109/SP46215.2023.10179440

  25. [25]

    Johannes Götzfried, Moritz Eckert, Sebastian Schinzel, and Tilo Müller. 2017. Cache attacks on Intel SGX. InProceedings of the 10th European Workshop on Systems Security. 1–6

  26. [26]

    Jinyu Gu, Bojun Zhu, Mingyu Li, Wentai Li, Yubin Xia, and Haibo Chen. 2022. A Hardware-Software Co-design for Efficient Intra-Enclave Isolation. InUSENIX Security Symposium. https://api.semanticscholar.org/CorpusID:252972178

  27. [27]

    Matthew R Guthaus, Jeffrey S Ringenberg, Dan Ernst, Todd M Austin, Trevor Mudge, and Richard B Brown. 2001. MiBench: A free, commercially representative embedded benchmark suite. InProceedings of the fourth annual IEEE international workshop on workload characterization. WWC-4 (Cat. No. 01EX538). IEEE, 3–14

  28. [28]

    David Kaplan, Jeremy Powell, and Tom Woller. 2016. AMD memory encryption. White paper13 (2016)

  29. [29]

    Arslan Khan, Muqi Zou, Kyungtae Kim, Dongyan Xu, Antonio Bianchi, and Dave Jing Tian. 2023. Fuzzing SGX enclaves via host program mutations. In2023 IEEE 8th European Symposium on Security and Privacy (EuroS&P). IEEE, 472–488

  30. [30]

    Mustakimur Rahman Khandaker, Yueqiang Cheng, Zhi Wang, and Tao Wei

  31. [31]

    In Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems

    COIN attacks: On insecurity of enclave untrusted interfaces in SGX. In Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems. 971–985

  32. [32]

    Patrick Koeberl, Steffen Schulz, Ahmad-Reza Sadeghi, and Vijay Varadharajan

  33. [33]

    InNinth Eurosys Conference 2014, EuroSys 2014, Amsterdam, The Netherlands, April 13- 16, 2014, Dick C

    TrustLite: a security architecture for tiny embedded devices. InNinth Eurosys Conference 2014, EuroSys 2014, Amsterdam, The Netherlands, April 13- 16, 2014, Dick C. A. Bulterman, Herbert Bos, Antony I. T. Rowstron, and Peter Druschel (Eds.). ACM, 10:1–10:14. doi:10.1145/2592798.2592824

  34. [34]

    Dayeol Lee, David Kohlbrenner, Shweta Shinde, Krste Asanovic, and Dawn Song. 2020. Keystone: an open framework for architecting trusted execution environments. InEuroSys ’20: Fifteenth EuroSys Conference 2020, Heraklion, Greece, April 27-30, 2020, Angelos Bilas, Kostas Magoutis, Evangelos P. Markatos, Dejan Kostic, and Margo I. Seltzer (Eds.). ACM, 38:1–3...

  35. [35]

    Jaehyuk Lee, Jinsoo Jang, Yeongjin Jang, Nohyun Kwak, Yeseul Choi, Changho Choi, Taesoo Kim, Marcus Peinado, and Brent ByungHoon Kang. 2017. Hacking in darkness: Return-oriented programming against secure enclaves. In26th USENIX Security Symposium (USENIX Security 17). 523–539

  36. [36]

    G. D. P. Mahidhar, Ramanujam Sarathi, and Balaji Srinivasan. 2020. Fluorescence Fiber Based Identification of Partial Discharges in Liquid Nitrogen for High- Temperature Superconducting Power Apparatus.IEEE Sensors Letters4, 2 (2020), 1–4. doi:10.1109/LSENS.2020.2971015

  37. [37]

    Hector Martin. 2021. M1RACLES: M1ssing Register Access Controls Leak EL0 State (CVE-2021-30747). https://m1racles.com/

  38. [38]

    Mathias Morbitzer, Benedikt Kopf, and Philipp Zieris. 2023. GuaranTEE: Intro- ducing control-flow attestation for trusted execution environments. In2023 IEEE 16th International Conference on Cloud Computing (CLOUD). IEEE, 547–553

  39. [39]

    Bernard Ngabonziza, Daniel Martin, Anna Bailey, Haehyun Cho, and Sarah Martin. 2016. TrustZone Explained: Architectural Features and Use Cases. In 2nd IEEE International Conference on Collaboration and Internet Computing, CIC 2016, Pittsburgh, PA, USA, November 1-3, 2016. IEEE Computer Society, 445–451. doi:10.1109/CIC.2016.065

  40. [40]

    Job Noorman, Pieter Agten, Wilfried Daniels, Raoul Strackx, Anthony Van Her- rewege, Christophe Huygens, Bart Preneel, Ingrid Verbauwhede, and Frank Piessens. 2013. Sancus: Low-cost Trustworthy Extensible Networked Devices 13 with a Zero-software Trusted Computing Base. InProceedings of the 22th USENIX Security Symposium, Washington, DC, USA, August 14-16...

  41. [41]

    David Patterson, Jeremy Bennett, Palmer Dabbelt, Cesare Garlati, GS Madhusu- dan, and Trevor Mudge. 2023. Embench: Open benchmarks for embedded plat- forms

  42. [42]

    Qualcomm

    Inc. Qualcomm. 2016. CVE-2016-2431: Qualcomm GPU Memory Vulnerability. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2431. Published: 2016-05-09

  43. [43]

    Qualcomm

    Inc. Qualcomm. 2018. CVE-2016-10423: Information Leak Vulnerability in Qual- comm Snapdragon Firmware. https://www.cvedetails.com/cve/CVE-2016-10423/. Published: 2018-04-18, Updated: 2018-05-01

  44. [44]

    Moinuddin K. Qureshi. 2018. CEASER: Mitigating Conflict-Based Cache Attacks via Encrypted-Address and Remapping. In51st Annual IEEE/ACM International Symposium on Microarchitecture, MICRO 2018, Fukuoka, Japan, October 20-24,

  45. [45]

    Efros, Eli Shechtman, and Oliver Wang

    IEEE Computer Society, 775–787. doi:10.1109/MICRO.2018.00068

  46. [46]

    Andrei Sabelfeld and David Sands. 2005. Dimensions and principles of declassifi- cation. In18th IEEE Computer Security Foundations Workshop (CSFW’05). IEEE, 255–269

  47. [47]

    Daniel Sanchez and Christos Kozyrakis. 2011. Vantage: Scalable and efficient fine-grain cache partitioning. InProceedings of the 38th annual international symposium on Computer architecture. 57–68

  48. [48]

    Abhiroop Sarkar and Alejandro Russo. 2024. HasTEE+ : Confidential Cloud Com- puting and Analytics with Haskell.CoRRabs/2401.08901 (2024). arXiv:2401.08901 doi:10.48550/ARXIV.2401.08901

  49. [49]

    Fletcher

    Sajin Sasy, Sergey Gorbunov, and Christopher W. Fletcher. 2018. ZeroTrace : Oblivious Memory Primitives from Intel SGX. In25th Annual Network and Distributed System Security Symposium, NDSS 2018, San Diego, California, USA, February 18-21, 2018. The Internet Society. https://www.ndss-symposium.org/wp- content/uploads/2018/02/ndss2018_02B-4_Sasy_paper.pdf

  50. [50]

    Michael Schwarz, Samuel Weiser, Daniel Gruss, Clémentine Maurice, and Stefan Mangard. 2017. Malware Guard Extension: Using SGX to conceal cache attacks. In International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment. Springer, 3–24

  51. [51]

    AMD Sev-Snp. 2020. Strengthening VM isolation with integrity protection and more.White Paper, January53, 2020 (2020), 1450–1465

  52. [52]

    Darius Suciu, Stephen McLaughlin, Laurent Simon, and Radu Sion. 2020. Horizon- tal privilege escalation in trusted applications. In29th USENIX Security Symposium (USENIX Security 20)

  53. [53]

    Qinhan Tan, Zhihua Zeng, Kai Bu, and Kui Ren. 2020. PhantomCache: Obfuscating Cache Conflicts with Localized Randomization.. InNDSS

  54. [54]

    Zahra Tarkhani and Anil Madhavapeddy. 2023. Information flow tracking for het- erogeneous compartmentalized software. InProceedings of the 26th International Symposium on Research in Attacks, Intrusions and Defenses. 564–579

  55. [55]

    Flavio Toffalini, Mathias Payer, Jianying Zhou, and Lorenzo Cavallaro. 2022. Designing a Provenance Analysis for SGX Enclaves. InAnnual Computer Security Applications Conference, ACSAC 2022, Austin, TX, USA, December 5-9, 2022. ACM, 102–116. doi:10.1145/3564625.3567994

  56. [56]

    Chia-Che Tsai, Jeongseok Son, Bhushan Jain, John McAvey, Raluca Ada Popa, and Donald E. Porter. 2020. Civet: An Efficient Java Partitioning Framework for Hardware Enclaves. In29th USENIX Security Symposium, USENIX Security 2020, August 12-14, 2020, Srdjan Capkun and Franziska Roesner (Eds.). USENIX Association, 505–522. https://www.usenix.org/conference/u...

  57. [57]

    Department of Justice

    U.S. Department of Justice. 2021. Department of Justice Seizes $2.3 Million in Cryptocurrency Paid to the Ransomware Extortionists Dark- side. https://www.justice.gov/opa/pr/department-justice-seizes-23-million- cryptocurrency-paid-ransomware-extortionists. Accessed: 2025

  58. [58]

    Jo Van Bulck, Marina Minkin, Ofir Weisse, Daniel Genkin, Baris Kasikci, Frank Piessens, Mark Silberstein, Thomas F Wenisch, Yuval Yarom, and Raoul Strackx

  59. [59]

    In27th USENIX Security Symposium (USENIX Security 18)

    Foreshadow: Extracting the keys to the intel SGX kingdom with transient Out-of-Order execution. In27th USENIX Security Symposium (USENIX Security 18). 991–1008

  60. [60]

    Kamakoti Veezhinathan. 2022. Building the SHAKTI microprocessor.Commun. ACM65, 11 (2022), 48–51

  61. [61]

    Yao Wang, Andrew Ferraiuolo, Danfeng Zhang, Andrew C Myers, and G Edward Suh. 2016. SecDCP: secure dynamic cache partitioning for efficient timing channel protection. InProceedings of the 53rd Annual Design Automation Conference. 1–6

  62. [62]

    Yuanpeng Wang, Ziqi Zhang, Ningyu He, Zhineng Zhong, Shengjian Guo, Qinkun Bao, Ding Li, Yao Guo, and Xiangqun Chen. 2023. Symgx: Detecting cross- boundary pointer vulnerabilities of SGX applications via static symbolic exe- cution. InProceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security. 2710–2724

  63. [63]

    Nico Weichbrodt, Anil Kurmus, Peter Pietzuch, and Rüdiger Kapitza. 2016. Async- Shock: Exploiting synchronisation bugs in Intel SGX enclaves. InComputer Security–ESORICS 2016: 21st European Symposium on Research in Computer Se- curity, Heraklion, Greece, September 26-30, 2016, Proceedings, Part I 21. Springer, 440–457

  64. [64]

    Mario Werner, Thomas Unterluggauer, Lukas Giner, Michael Schwarz, Daniel Gruss, and Stefan Mangard. 2019. ScatterCache: Thwarting Cache Attacks via Cache Set Randomization. In28th USENIX Security Symposium, USENIX Security 2019, Santa Clara, CA, USA, August 14-16, 2019, Nadia Heninger and Patrick Traynor (Eds.). USENIX Association, 675–692. https://www.us...

  65. [65]

    HanJae Yoon and ManHee Lee. 2022. SGXDump: a repeatable code-reuse attack for extracting SGX enclave memory.Applied Sciences12, 15 (2022), 7655. 14