Pith. sign in

REVIEW 3 major objections 5 minor 49 references

ShieldMMU: Detecting and Defending against Controlled-Channel Attacks in Shielding Memory System

T0 review · 3 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash

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

Pith's one-line read ShieldMMU lets the MMU detect a malicious OS clearing page-table bits, restore the page, and keep the enclave running.

desk verdict The central defense never triggers for the canonical attack: clearing only the PTE present bit leaves the DD-Tree leaf intact, so the integrity check passes and the MMU reports the fault to the OS just as it would without ShieldMMU. read the letter →

arxiv 2509.03879 v1 pith:BCNRTFXP submitted 2025-09-04 cs.CR cs.SYeess.SY

Gang Liu , Ningjie Li , Cen Chen This is my paper · ORCID
classification cs.CRcs.SYeess.SY
keywords controlled-channelattacksIntelSGXpagetableentriesMerkletreeMMUshieldingsystemside-channeldefensefault
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's claim is that a controlled-channel attack—where a malicious OS clears the present bit of an enclave's page-table entries to spy on which pages are accessed—can be stopped at the memory management unit itself, before the page fault is ever reported. ShieldMMU adds a Merkle-tree-like structure called the DD-Tree whose leaves record the true present bit and physical address of each protected page-table entry, with the root held inside the trusted enclave. When the MMU hits a present-bit-zero entry, it checks the tree's hash path; a mismatch signals a deliberate attack, and the MMU then restores the present bit and uses the leaf's physical address to satisfy the access, so the OS never learns the access pattern. If the hash path verifies, the fault is a legitimate missing-page event and is forwarded to the OS normally. A sympathetic reader would care because this shifts defense from application annotations and detection-only schemes to a hardware behavior that protects and continues execution automatically.

What carries the argument

DD-Tree (Defense Tree): a Merkle-tree variant used as the trusted record for page-table entries. Each leaf stores the present bit and physical address of one PTE, keyed by the linearized virtual address; internal nodes store hashes of children, and the root is kept in secure memory inside the TEE. In ShieldMMU, the MMU consults the DD-Tree whenever a PTE lookup finds present=0; a failed leaf-to-root hash check marks the entry as attacked and triggers automatic PTE restoration, while a passing check means the page is genuinely not present and the fault is handled by the OS. The defense forest splits one large tree into per-PUD trees to shorten verification paths.

What would settle it

Modify the simulated attacker so that, in addition to clearing the present bit of a target PTE, it rewrites the corresponding DD-Tree leaf's stored physical address to a different value. If the MMU's integrity check fails and then completes the access using that tampered address, the defense has restored to attacker-chosen data—falsifying the claim that ShieldMMU restores the true page. A simpler observational check: compare the physical address the MMU uses after restoration with the enclave's actual backing page in the simulator.

Watch

Extended reading notes

Core claim

The paper's central claim is that the MMU can distinguish an attacker-cleared present bit from a genuinely absent page and, in the attack case, resolve the fault itself without involving the OS. The mechanism: each protected PTE has a corresponding leaf in the DD-Tree storing the true present bit and physical base address; non-leaf nodes store hashes of children; and the root resides in the TEE. When the page walker encounters a present-bit-zero PTE, it halts translation and traverses the DD-Tree, hashing the leaf-to-root path. If the root hash matches, the PTE state is trusted as a legitimate OS page-management decision, and the fault proceeds to the OS. If not, the PTE has been tampered wi

Load-bearing premise

The defense assumes the DD-Tree leaf nodes—the only source of the true physical address used for restoration—are intact when the MMU reads them, even though they are stored in memory the malicious OS can write to.

Editorial extensions

If this is right

  • Protected page-table entries can no longer leak access patterns through page-fault events: a successfully restored access produces no fault interrupt and no OS-visible signal.
  • The approach removes the programmer burden of annotating secret-dependent code, since protection is applied automatically to application PTEs by the MMU and the defense tree.
  • Legitimate OS memory management is preserved: when integrity verification succeeds, the present-bit-zero condition is treated as a real missing page and the OS handles it normally.
  • The reported overhead in simulation is low on unchanged benchmark workloads, and the defense blocks the large majority of leakage attempts while keeping latency acceptable for security-critical applications.
  • Because detection and restoration happen in the page-walk path, the design changes the MMU behavior itself rather than requiring application rewrites or a separate trusted OS component.

Reading between the lines

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

  • The restoration step is only as trustworthy as the leaf content; if an attacker corrupts a DD-Tree leaf itself, the hash check fails but the MMU would restore to the tampered physical address. A hardened variant should store leaf metadata in secure memory or authenticate each leaf with a keyed MAC.
  • The same MMU-side integrity mechanism could be extended to other PTE fields—user/supervisor, read/write, accessed, dirty—that a malicious OS might manipulate as side channels, not just the present bit.
  • Since the DD-Tree is organized by PUD address, per-process isolation could be made explicit by keying trees on the PGD/CR3 value, which would also make the defense easier to apply to multi-process workloads.
  • A natural empirical next step is to test an attacker that both clears the present bit and performs the actual page swap described in the paper; the paper argues swapping is too slow for practical attacks, but such a test would show whether restoration remains correct when the PTE is genuinely gone.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. ShieldMMU proposes a hardware/MMU-level defense against controlled-channel (page-fault) attacks on Intel SGX. The design augments the MMU with a Merkle-tree-like structure, the DD-Tree, whose leaves store a shadow copy of each protected PTE's present bit and physical address, with tree roots stored in secure memory. When the MMU encounters a PTE with present bit 0, it is supposed to verify the DD-Tree path; on verification failure it treats the situation as an attack, uses the physical address stored in the leaf to complete address translation, and restores the present bit to 1, thereby preventing the fault from being reported to a malicious OS. The paper includes a gem5 full-system implementation, a security argument based on hash collision resistance, and experiments showing moderate performance overhead and a claimed defense success rate above 90%.

Significance. If the proposed mechanism worked as described, it would be a valuable contribution: a hardware-assisted MMU defense that not only detects but also transparently recovers from controlled-channel attacks, with acceptable overhead and no developer annotations. The paper also includes a practical implementation in gem5 and evaluates several benchmark workloads. However, the central detection logic is unsound with respect to the very attack it targets. The DD-Tree authenticates the shadow leaf metadata, not the page table entry itself, so an attacker who clears only the PTE present bit leaves the tree unchanged and the integrity check succeeds. The defense path is therefore not triggered by the canonical controlled-channel attack. This is a load-bearing flaw that invalidates the paper's main claim, independent of the secondary concern that restoration uses leaf values from unverified memory.

major comments (3)
  1. [§5.2, §5.5 steps 5–6, §3.1] The paper states in §5.2 that each leaf node stores 'the present bit and physical base address of a page table entry,' and in §5.5 step 5 the MMU 'verifies the integrity of the hash path from the leaf to the root.' This authenticates the leaf's stored metadata, not the PTE found during page-table traversal. In the canonical controlled-channel attack described in §3.1, the malicious OS clears the present bit of the PTE but does not modify the DD-Tree leaf; the leaf still contains present=1 and the original physical address, so the hash path verifies successfully. The MMU then follows the 'Case of Integrity Verification Success' branch and reports a page fault to the OS. Thus the detection condition 'PTE exists but present bit is 0 and integrity verification fails' is never met by the attack the paper targets. The design lacks any comparison between the actual PTE contents and the protecte
  2. [§5.5 step 7 and §5.2] Even in the integrity-failure path, the restoration mechanism uses the physical address 'stored in the leaf node of the defense tree' as the trusted ground truth. But the threat model in §5.1 grants the OS full memory-management control, and the DD-Tree leaves are not placed in a trusted region; only the root is said to reside in the TEE. An attacker who modifies a leaf node to a chosen present bit and physical address causes the hash path to fail, after which the MMU performs restoration using the attacker-controlled leaf value. The security analysis in §5.6 only argues that collision resistance prevents an attacker from keeping the root hash unchanged; it does not establish that the leaf's stored address is trustworthy after a detected tampering. The design therefore fails open: a detected attack supplies the very value used to bypass the OS.
  3. [§6.1, §6.2.4 and Table 5] The evaluation measures defense success as the attacker's page-fault handler receiving no faults, which is the direct effect of the MMU not raising a fault and therefore partially encodes the mechanism itself. Table 5 reports 'shieldMMU Failures (Leakages)' under an attack that clears PTE present bits only; because the DD-Tree integrity check succeeds in that scenario, the reported low leakage counts reflect the simulator's defensive behavior only if the implementation compares the PTE against the leaf, which is not described in §5.5. The benchmark results therefore do not demonstrate security against the canonical attack, and no experiment exercises the fail-open leaf-tampering scenario. A meaningful evaluation would need to test an adversary who clears the PTE without modifying the tree, as well as an adversary who modifies leaf nodes, and measure whether the MMU's behavior differs fro
minor comments (5)
  1. [§5.2 and §5.4] The text repeatedly uses 'victim bits' where it appears to mean 'valid bits' or 'present bits' of the PTE; please correct this terminology.
  2. [§2.3] The Merkle tree reference is cited as '[? ]' in the sentence 'The MT [? ][16]'—a missing citation placeholder that should be filled.
  3. [§5.3.1] The memory-overhead analysis is incompletely described: the sentence 'the memory required for storing hash values accounts for of the total protected memory' is missing its fraction, and the claimed total overhead formula '(1/(m-1)+1/m)' is not clearly derived. Please clarify the parameters and derivation.
  4. [Figure 7 and Table 4] Figure 7's axis labels appear as a string of '/uni...' encoded values rather than readable text, and Table 4's formatting is ambiguous. These should be fixed so the results are interpretable.
  5. [§5.5] The two 'Case of Integrity Verification Success/Failure' subsections repeat the workflow already given in steps 1–8. Consider condensing to avoid redundancy.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the Merkle-tree security argument is self-contained; the paper's serious flaws are correctness/trust-model gaps, not circular derivations.

full rationale

The derivation chain is not circular under the review rubric. The central security argument is the standard Merkle-tree collision-resistance analysis in Section 5.6: any change to a leaf changes the trusted root hash, so the root can authenticate the tree; no parameter is fitted to data and then renamed a prediction, and no load-bearing conclusion is imported from a self-citation ([23,24] are peripheral ORAM/benchmark references). The evaluation metric (attacker's page-fault handler receives no faults) is the mechanism's direct behavioral output, but measuring intended behavior is not a circular reduction. The paper does, however, contain serious correctness/trust-model gaps that should be weighed separately from circularity: (1) Section 3.1's canonical attack clears only the PTE present bit and leaves the DD-Tree leaf and hash path unchanged, so Section 5.5's integrity check succeeds and the fault is reported to the OS, meaning the stated detection condition is not reached by the attack it targets; (2) Section 5.5 step 7 restores using the leaf-stored physical address in the integrity-failure branch, but leaf nodes are in ordinary memory per Section 5.2, and a failed check means the leaf is inconsistent with the trusted root, so the restoration is not grounded in a trusted value. These are omitted-proof/logical problems for the security claim, not cases where the paper's result reduces to its inputs by construction, so the circularity score is 0.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The central claim depends on the assumption that the OS cannot tamper with the very tree nodes that provide the restoration values. No free parameters are fitted to data in a way that manufactures the result, but several design choices (m=8, height limit, application-PTE-only scope) are set by hand and affect the reported overhead.

free parameters (3)
  • m (arity of DD-Tree) = 8
    Section 6.2.3 compares 2-, 4-, 6-, and 8-ary trees and selects the 8-ary tree based on measured runtime and memory overhead; this is a design choice fitted to the evaluation, not derived from first principles.
  • DD-Tree height limit = 8 layers
    Section 5.3 states the tree height is limited to no more than 8 layers to improve efficiency; this bound is chosen by hand.
  • Protected PTE scope = application PTEs only, not system PTEs
    Section 5.4 excludes system PTE protection under the rationale of 'higher stability requirements and lower attack surface', a scoping choice that shrinks the defended attack surface.
assumptions (4)
  • domain assumption The OS can clear and set PTE present bits but cannot otherwise redirect a virtual address to a different physical EPC page.
    Section 5.1 says the OS manages enclave memory pages but cannot observe contents; the attack model only uses present-bit clearing. The paper does not explicitly discuss EPCM restrictions on physical address swaps.
  • ad hoc to paper Leaf and internal nodes of the DD-Tree, stored in normal memory, are not modified by the malicious OS during an attack.
    Section 5.2 places all tree nodes except the root in memory; the threat model in Section 5.1 grants the OS unrestricted memory access, so this protection is assumed without justification.
  • domain assumption The MMU can be modified in real hardware to perform hash-tree verification and use the leaf physical address without OS involvement.
    The design is implemented only in gem5's software MMU; the paper does not discuss hardware cost, cycle impact on every translation, or whether Intel would expose this behavior.
  • standard math Hash function collision resistance is a valid cryptographic assumption.
    Section 5.6 uses the collision resistance of H to argue an attacker cannot forge a matching root hash.

how reviews work

0 comments
Cite this review

Pith. "Pith review of ShieldMMU: Detecting and Defending against Controlled-Channel Attacks in Shielding Memory System." pith.science (2026). https://pith.science/paper/BCNRTFXP

@misc{pith2026250903879,
  author       = {Pith},
  title        = {Pith review of: ShieldMMU: Detecting and Defending against Controlled-Channel Attacks in Shielding Memory System},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/BCNRTFXP}},
  note         = {Machine review of arXiv:2509.03879}
}
read the original abstract

Intel SGX and hypervisors isolate non-privileged programs from other software, ensuring confidentiality and integrity. However, side-channel attacks continue to threaten Intel SGX's security, enabling malicious OS to manipulate PTE present bits, induce page faults, and steal memory access traces. Despite extensive research, existing defenses focus on detection or rely on impractical solutions. This paper presents ShieldMMU, a comprehensive solution for mitigating controlled channel attacks, balancing compatibility, performance, and usability. Leveraging a Merkle Tree-inspired Defense Tree (DD-Tree), ShieldMMU protects PTE integrity by detecting, locating, and restoring attacked PTEs. It identifies MMU page table lookup events and side-channel attacks, promptly restoring PTE parameters to prevent page fault traps and ensure secure non-privileged application operation within SGX. Our experiments confirm ShieldMMU's enhanced security and acceptable latency performance.

Figures

Figures reproduced from arXiv: 2509.03879 by the authors.

Figure 1
Figure 1. Merkle Tree while the root is stored in a trusted secure environment and never leaves it. Each time a data integrity is verified, the entire path from the leaf node to the hash of the root is verified. And because the root never leaves the TEE, it reflects the latest state of the data, provides a basis for tree-wide integrity checks, and is able to detect any tampering with the data. MT has been one of the most comm… view at source ↗
Figure 2
Figure 2. controlled side-channel attack. Since a malicious OS can manipulate the page tables of a pro￾tected enclave program, it can determine which memory pages the enclave program intends to access by setting reserved bits in the [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Defense Tree (Part of the node) as illustrated in [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Defense Forest with the cost of each hash computation proportional to [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 4
Figure 4. Figure 4: Defense Forest 5.4 Creation and Addition of the Defense Tree The primary challenge in constructing a defensive tree (DD-Tree) lies in efficiently creating, adding, and deleting each node. To re￾duce memory overhead and improve verification efficiency, our implementatio…
Figure 5
Figure 5. Figure 5: Addition of the Defense Tree. ○1 : CPU first mem￾ory access attempt; ○2 : TLB miss; ○3 : Trigger page fault interrupt; ○4 : OS updates TLB and PT; ○5 : CPU second memory access attempt and hit TLB cache. Pre-Addition after ○3 , Formal Addition after ○5 5.4.2 Formal Add…
Figure 7
Figure 7. Figure 7: Prformance Metrics Normalized to Baseline. simTicks: Number of ticks simulated (Tick). simInsts: Number of [PITH_FULL_IMAGE:figures/full_fig_p011_7.png]
Figure 8
Figure 8. Figure 8: m-ary DD-Tree Runtime Comparison. 8-ary DD tree is higher than in other trees, with a fixed number of leaf nodes, the 8-ary DD tree possesses fewer non-leaf nodes and a lower tree height, thereby achieving more efficient verification and update operations. Consequently…
Figure 9
Figure 9. Figure 9: m-ary DD-Tree Memory Comparison. represents the number of virtual addresses accessed by the bench￾mark that the attacker could still steal after enabling the proposed shieldMMU mechanism. 100 visits and 1000 visits respectively indi￾cate programs that have performed mo…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

49 extracted references · 45 canonical work pages

  1. [1]

    Shaizeen Aga and Satish Narayanasamy. 2019. InvisiPage: Oblivious demand paging for secure enclaves. In Proceedings of the 46th International Symposium on Computer Architecture. 372–384

    work page 2019

  2. [2]

    Adil Ahmad, Byunggill Joe, Yuan Xiao, Yinqian Zhang, Insik Shin, and Byoungy- oung Lee. 2019. OBFUSCURO: A commodity obfuscation engine on Intel SGX. In Network and Distributed System Security Symposium

    work page 2019

  3. [3]

    Adil Ahmad, Kyungtae Kim, Muhammad Ihsanulhaq Sarfaraz, and Byoungyoung Lee. 2018. OBLIVIATE: A Data Oblivious Filesystem for Intel SGX.. In NDSS

    work page 2018

  4. [4]

    Ittai Anati, Shay Gueron, Simon Johnson, and Vincent Scarlata. 2013. Innovative technology for CPU based attestation and sealing. In Proceedings of the 2nd international workshop on hardware and architectural support for security and privacy, Vol. 13. ACM New York, NY, USA

    work page 2013

  5. [5]

    Andrew Baumann, Marcus Peinado, and Galen Hunt. 2015. Shielding applications from an untrusted cloud with haven. ACM Transactions on Computer Systems (TOCS) 33, 3 (2015), 1–26

    work page 2015

  6. [6]

    Diana Berbecaru and Luca Albertalli. 2008. On the performance and use of a space-efficient merkle tree traversal algorithm in real-time applications for wireless and sensor networks. In 2008 IEEE International Conference on Wireless and Mobile Computing, Networking and Communications . IEEE, 234–240

    work page 2008

  7. [7]

    Ferdinand Brasser, Srdjan Capkun, Alexandra Dmitrienko, Tommaso Frassetto, Kari Kostiainen, and Ahmad-Reza Sadeghi. 2019. DR. SGX: Automated and adjustable side-channel protection for SGX using data location randomization. In Proceedings of the 35th Annual Computer Security Applications Conference . 788–800

    work page 2019

  8. [8]

    Kistowski

    James Bucek, Klaus-Dieter Lange, and Jóakim v. Kistowski. 2018. SPEC CPU2017: Next-generation compute benchmark. In Companion of the 2018 ACM/SPEC In- ternational Conference on Performance Engineering . 41–42

    work page 2018

Show all 49 references
  1. [9]

    Stephen Checkoway and Hovav Shacham. 2013. Iago attacks: why the system call API is a bad untrusted RPC interface. SIGARCH Comput. Archit. News 41, 1 (March 2013), 253–264. https://doi.org/10.1145/2490301.2451145

    2013

  2. [10]

    Sanchuan Chen, Xiaokuan Zhang, Michael K Reiter, and Yinqian Zhang. 2017. Detecting privileged side-channel attacks in shielded execution with Déjá Vu. In Proceedings of the 2017 ACM on Asia Conference on Computer and Communications Security. 7–18

    2017

  3. [11]

    Zhengguo Chen, Youtao Zhang, and Nong Xiao. 2020. Cachetree: Reducing integrity verification overhead of secure nonvolatile memories.IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 40, 7 (2020), 1340– 1353

    2020

  4. [12]

    Yueqiang Cheng, Xuhua Ding, and Robert Deng. 2013. Appshield: Protecting ap- plications against untrusted operating system. Singaport Management University Technical Report, SMU-SIS-13 101 (2013)

    2013

  5. [13]

    John Criswell, Nathan Dautenhahn, and Vikram Adve. 2014. Virtual ghost: Protecting applications from hostile operating systems.ACM SIGARCH Computer Architecture News 42, 1 (2014), 81–96

    2014

  6. [14]

    Lee, Nachiketh Potlapally, and Lionel Torres

    Reouven Elbaz, David Champagne, Catherine Gebotys, Ruby B. Lee, Nachiketh Potlapally, and Lionel Torres. 2009. Hardware Mechanisms for Memory Authen- tication: A Survey of Existing Techniques and Engines . 1–22. https://doi.org/10. 1007/978-3-642-01004-0_1

    2009

  7. [15]

    Alexander Freij, Huiyang Zhou, and Yan Solihin. 2021. Bonsai merkle forests: Efficiently achieving crash consistency in secure persistent memory. InMICRO-54: 54th Annual IEEE/ACM International Symposium on Microarchitecture. 1227–1240

    2021

  8. [16]

    Blaise Gassend, G Edward Suh, Dwaine Clarke, Marten Van Dijk, and Srinivas Devadas. 2003. Caches and hash trees for efficient memory integrity verification. In The Ninth International Symposium on High-Performance Computer Architecture,

    2003

  9. [17]

    Owen S Hofmann, Sangman Kim, Alan M Dunn, Michael Z Lee, and Emmett Witchel. 2013. Inktag: Secure applications on an untrusted operating system. In Proceedings of the eighteenth international conference on Architectural support for programming languages and operating systems . 265–278

    2013

  10. [18]

    Jianming Huang and Yu Hua. 2021. A Write-Friendly and Fast-Recovery Scheme for Security Metadata in Non-Volatile Memories. In 2021 IEEE Inter- national Symposium on High-Performance Computer Architecture (HPCA) . https: //doi.org/10.1109/hpca51647.2021.00038

    2021

  11. [19]

    Sangho Lee, Ming-Wei Shih, Prasun Gera, Taesoo Kim, Hyesoon Kim, and Marcus Peinado. 2017. Inferring fine-grained control flow inside{SGX} enclaves with branch shadowing. In 26th USENIX Security Symposium (USENIX Security 17) . 557–574

    2017

  12. [20]

    Christian Lesjak, Daniel Hein, and Johannes Winter. 2015. Hardware-security technologies for industrial IoT: TrustZone and security controller. (2015), 002589– 002595

    2015

  13. [21]

    David Lie, Chandramohan A Thekkath, and Mark Horowitz. 2003. Implement- ing an untrusted operating system on trusted hardware. In Proceedings of the nineteenth ACM symposium on Operating systems principles . 178–192

    2003

  14. [22]

    Ankur Limaye and Tosiron Adegbija. 2018. A workload characterization of the spec cpu2017 benchmark suite. , 149–158 pages

    2018

  15. [23]

    Gang Liu, Kenli Li, Zheng Xiao, and Rujia Wang. 2022. Ps-oram: Efficient crash consistency support for oblivious ram on nvm. In Proceedings of the 49th Annual International Symposium on Computer Architecture . 188–203

    2022

  16. [24]

    Gang Liu, Zheng Xiao, kenli Li, and Rujia Wang. 2025. HM-ORAM: A Light- weight Crash-consistent ORAM Framework on Hybrid Memory System. ACM Transactions on Storage 21, 2 (2025), 1–28

    2025

  17. [25]

    Jason Lowe-Power, Abdul Mutaal Ahmad, Ayaz Akram, Mohammad Alian, Rico Amslinger, Matteo Andreozzi, Adrià Armejach, Nils Asmussen, Brad Beckmann, Srikant Bharadwaj, et al. 2020. The gem5 simulator: Version 20.0+. arXiv preprint arXiv:2007.03152 (2020)

    2020 arXiv

  18. [26]

    Jonathan M McCune, Bryan J Parno, Adrian Perrig, Michael K Reiter, and Hiroshi Isozaki. 2008. Flicker: An execution infrastructure for TCB minimization. In Proceedings of the 3rd ACM SIGOPS/EuroSys European Conference on Computer Systems 2008. 315–328

    2008

  19. [27]

    Frank McKeen, Ilya Alexandrovich, Ittai Anati, Dror Caspi, Simon Johnson, Rebekah Leslie-Hurd, and Carlos Rozas. 2016. Intel ® software guard extensions (intel® sgx) support for dynamic memory management inside an enclave. , 9 pages

    2016

  20. [28]

    Frank McKeen, Ilya Alexandrovich, Ittai Anati, Dror Caspi, Simon Johnson, Rebekah Leslie-Hurd, and Carlos Rozas. 2016. Intel ® software guard extensions ShieldMMU: Detecting and Defending against Controlled-Channel Attacks in Shielding Memory System XXXX, XXXXX, XXXXX (intel® ...

    2016

  21. [29]

    Frank McKeen, Ilya Alexandrovich, Alex Berenzon, Carlos V Rozas, Hisham Shafi, Vedvyas Shanbhogue, and Uday R Savagaonkar. 2013. Innovative instructions and software model for isolated execution. Hasp@ isca 10, 1

    2013

  22. [30]

    Frank McKeen, Ilya Alexandrovich, Alex Berenzon, Carlos V Rozas, Hisham Shafi, Vedvyas Shanbhogue, and Uday R Savagaonkar. 2013. Innovative instructions and software model for isolated execution. Hasp@ isca 10, 1 (2013)

    2013

  23. [31]

    Oleksii Oleksenko, Bohdan Trach, Robert Krahn, Mark Silberstein, and Christof Fetzer. 2018. Varys: Protecting{SGX} enclaves from practical{Side-Channel} attacks. In 2018 Usenix Annual Technical Conference (USENIX ATC 18) . 227–240

    2018

  24. [32]

    Meni Orenbach, Andrew Baumann, and Mark Silberstein. 2020. Autarky: Closing controlled channels with self-paging enclaves. In Proceedings of the Fifteenth European Conference on Computer Systems . 1–16

    2020

  25. [33]

    Dan RK Ports and Tal Garfinkel. 2008. Towards Application Security on Untrusted Operating Systems.. In HotSec

    2008

  26. [34]

    Brian Rogers, Siddhartha Chhabra, Milos Prvulovic, and Yan Solihin. 2007. Using address independent seed encryption and bonsai merkle trees to make secure processors os-and performance-friendly. In 40th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO 2007) ...

    2007

  27. [35]

    Sajin Sasy, Sergey Gorbunov, and Christopher W Fletcher. 2017. ZeroTrace: Oblivious memory primitives from Intel SGX. Cryptology ePrint Archive

    2017

  28. [36]

    Rakin Muhammad Shadab, Yu Zou, Sanjay Gandham, Amro Awad, and Mingjie Lin. 2023. A secure computing system with hardware-efficient lazy bonsai merkle tree for fpga-attached embedded memory. IEEE Transactions on Dependable and Secure Computing 21, 4 (2023), 3262–3279

    2023

  29. [37]

    Ming-Wei Shih, Sangho Lee, Taesoo Kim, and Marcus Peinado. 2017. T-SGX: Eradicating Controlled-Channel Attacks Against Enclave Programs.. In NDSS, Vol. 6. 15–43

    2017

  30. [38]

    Shweta Shinde, Zheng Leong Chua, Viswesh Narayanan, and Prateek Saxena

  31. [39]

    Rohit Sinha, Sriram Rajamani, and Sanjit A Seshia. 2017. A compiler and verifier for page access oblivious computation. In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering . 649–660

    2017

  32. [40]

    Richard Ta-Min, Lionel Litty, and David Lie. 2006. Splitting interfaces: Making trust between applications and operating systems configurable. In Proceedings of the 7th symposium on Operating systems design and implementation . 279–292

    2006

  33. [41]

    Jan Wichelmann, Anja Rabich, Anna Pätschke, and Thomas Eisenbarth. 2024. Obelix: Mitigating side-channels through dynamic obfuscation. In 2024 IEEE Symposium on Security and Privacy (SP) . IEEE, 4182–4199

    2024

  34. [42]

    Yuanzhong Xu, Weidong Cui, and Marcus Peinado. 2015. Controlled-channel attacks: Deterministic side channels for untrusted operating systems. In 2015 IEEE Symposium on Security and Privacy . IEEE, 640–656

    2015

  35. [43]

    Sujay Yadalam, Vinod Ganapathy, and Arkaprava Basu. 2020. SGXL: Security and Performance for Enclaves Using Large Pages. ACM Transactions on Architecture and Code Optimization (TACO) 18, 1 (2020), 1–25

    2020

  36. [44]

    Jisoo Yang and Kang G Shin. 2008. Using hypervisor to provide data secrecy for user applications on a per-page basis. In Proceedings of the fourth ACM SIG- PLAN/SIGOPS international conference on Virtual execution environments . 71–80

    2008

  37. [45]

    Fengzhe Zhang, Jin Chen, Haibo Chen, and Binyu Zang. 2011. Cloudvisor: retrofitting protection of virtual machines in multi-tenant cloud with nested virtualization. In Proceedings of the twenty-third acm symposium on operating systems principles. 203–216

    2011

  38. [46]

    Pan Zhang, Chengyu Song, Heng Yin, Deqing Zou, Elaine Shi, and Hai Jin. 2020. Klotski: Efficient obfuscated execution against controlled-channel attacks. In Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operatin...

    2020

  39. [47]

    Jishen Zhao, Sheng Li, Doe Hyun Yoon, Yuan Xie, and Norman P Jouppi. 2013. Kiln: Closing the performance gap between systems with and without persistence support. In Proceedings of the 46th Annual IEEE/ACM International Symposium on Microarchitecture. 421–432

    2013

  40. [2003]

    Proceedings

    HPCA-9 2003. Proceedings. IEEE, 295–306

    2003

  41. [2016]

    In Proceedings of the 11th ACM on Asia Conference on Computer and Communications Security

    Preventing page faults from telling your secrets. In Proceedings of the 11th ACM on Asia Conference on Computer and Communications Security . 317–328

Pith tools

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