Pith. sign in

REVIEW 3 major objections 5 minor 52 references

Adaptive and Efficient Dynamic Memory Management for Hardware Enclaves

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

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

Pith's one-line read SGX2 can cut enclave launch time by 28–93%, but naive dynamic memory use slows execution by up to 58%; four optimizations eliminate the slowdown.

desk verdict Solid, honest SGX2/EDMM evaluation: the overhead analysis and optimizations hold up on the tested workloads, but the headline 'effectively eliminated' rests on parameters picked using those same benchmarks. read the letter →

arxiv 2504.16251 v3 pith:SBR676F4 submitted 2025-04-22 cs.OS cs.CR

Vijay Dhanraj , Harpreet Singh Chawla , Tao Zhang , Daniel Manila , Eric Thomas Schneider , Erica Fu , Mona Vij , Chia-Che Tsai
show 1 more author
Donald E. Porter
This is my paper · ORCID
classification cs.OScs.CR
keywords EDMMIntelSGXSGX2enclavememorymanagementGraminelibraryOStrustedexecutionenvironmentperformanceoptimization
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

Intel's SGX2 hardware lets an enclave grow and shrink its memory while running, instead of fixing every page before launch. The paper argues this is worth having because it cuts enclave loading time by 28–93%, but shows that the obvious ways to use it—mapping pages when the application asks, or on first access—can slow execution by up to 58%, because the enclave and the untrusted OS must handshake over every mapping change. The central result is that four optimizations (pre-allocating a modest initial heap, batching page additions across a contiguous range, faulting in several neighboring pages at once, and lazily caching freed pages) remove the runtime penalty, making EDMM comparable to or better than SGX1 static allocation on the tested workloads. If this holds, dynamic enclave memory becomes practical for library OSes and language runtimes without forcing a choice between slow startup and a fixed memory footprint.

What carries the argument

The load-bearing mechanism is the hardware-enforced mutual-distrust protocol for changing an enclave's virtual memory: the untrusted OS proposes a mapping change through system-tier instructions (EAUG, EMODT, EMODPR) and the enclave must approve it with EACCEPT before the change is usable. This handshake forces at least three enclave crossings to add a mapping, five under demand paging, and nine to remove one, and a demand fault costs roughly 30 microseconds versus 8 microseconds in a normal process. The paper's four optimizations are all aimed at this mechanism: +pre allocates an initial heap at launch when mapping is cheap; +batch makes the kernel issue many EAUGs for one round trip through a new madvise path; +demand<N> maps up to N neighboring pages on the first fault; and +lf caches freed pages instead of unmapping them.

What would settle it

Run an SGX2 workload with an allocation pattern unlike the three tested ones—many small temporary mappings or heavy munmap churn, or memory pressure that forces EPC reclamation—using the paper's default settings (64 MB pre-allocation, demand windows of 8 or 64 pages, lazy threshold 5 or 15%); if end-to-end time regresses relative to static allocation by the 28–58% seen for naive EDMM, the claim of eliminated overheads fails for that setting.

Watch

Extended reading notes

Core claim

The paper's central claim is that the runtime overhead of EDMM is not an inherent cost of dynamic enclave memory, but an artifact of doing mapping changes one page at a time. Naive EDMM, whether it maps on mmap or on first access, slows GCBench by 41% and 58% and RBench by 5% and 10% relative to SGX1 static allocation, even though it cuts enclave loading time by 28–93%. The paper shows that combining 64 MB pre-allocation with batched page additions and 8- or 64-page contiguous demand allocation, plus lazy frees at a 5–15% threshold, turns the GCBench overhead into a 1.8–2.8% speedup over static and lets RBench beat static at the 15% lazy threshold, while keeping much of the startup gain. The stated conclusion is that EDMM's dynamic memory benefits can be retained without a performance penalty, provided the mapping protocol is amortized across regions and frees are deferred.

Load-bearing premise

The load-bearing premise is that the configuration parameters tested here—64 MB of pre-allocation, demand windows of 8 or 64 pages, and lazy-free thresholds of 5 or 15%—are representative or predictable enough for other SGX2 workloads, since the paper picks them by inspecting results on the same benchmarks and leaves memory-pressure experiments to future work.

Editorial extensions

If this is right

  • Enclaves can be launched small and expanded on demand, so applications with input-dependent memory use no longer over-provision heap pages up front; the optimized configurations keep most of the 28–93% loading-time improvement.
  • Runtimes can enable EDMM without sacrificing runtime speed: on GCBench the overhead drops from 28% (with batch) or 36% (with demand-8) to small gains over static, and RBench beats static at a 15% lazy threshold.
  • Demand paging in an enclave should be region-based rather than page-based: mapping 8 or 64 neighboring pages per fault is what makes demand allocation competitive with eager mapping.
  • Unmapping is the most expensive enclave operation, so caching freed pages instead of returning them to the kernel is the decisive optimization for allocator-heavy workloads like garbage-collected applications.
  • The batch-allocation optimization requires a new madvise interface in the Linux SGX driver that the authors plan to upstream; until it lands, applications can only get the full benefit of +batch with a patched driver.

Reading between the lines

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

  • Beyond the paper: the same OS-proposes/enclave-accepts handshake appears in VM-style TEEs like Intel TDX and AMD SEV-SNP, so region-batched mapping and lazy free should transfer to guest-OS memory managers there, though the paper does not evaluate them.
  • Beyond the paper: because the optimization parameters are tuned on the same benchmarks that are used to report the gains, a held-out workload with a different allocation pattern could require retuning 64 MB, the 8/64-page windows, and the 5/15% thresholds; the headline results are an upper bound until that is tested.
  • Beyond the paper: lazy free deliberately breaks strict POSIX semantics by not faulting on an access to a freed page; a compatible variant could keep a guard mapping and lazily re-fault only on real access, a testable extension the paper does not explore.
  • Beyond the paper: the AEX-Notify hardware feature cited in the paper could remove some of the remaining context switches in the demand-allocation flow, potentially making even single-page demand faults cheap enough that region batching becomes unnecessary.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. The paper studies Enclave Dynamic Memory Management (EDMM) in SGX2 using Gramine as a representative library OS. It first quantifies the performance of two straightforward EDMM adoption strategies (immediate mapping and demand allocation), showing enclave loading time reductions of 28--93% but runtime slowdowns of up to 58% on GCBench. It then proposes and evaluates four optimizations: pre-allocation (+pre), batched allocation via a custom madvise ioctl (+batch), contiguous demand allocation (+demand<N>), and lazy free (+lf). The optimized configurations are reported to bring EDMM performance to parity with or above static allocation on GCBench, RBench, and Redis, while retaining much of the startup benefit. The paper concludes that the overheads of EDMM can be effectively eliminated while preserving its flexibility and space-efficiency advantages.

Significance. If the results hold beyond the tested configurations, the paper makes a useful contribution: it provides the first systematic implementation and evaluation of EDMM in a mainstream library OS, quantifies the hardware context-switch costs that make dynamic mapping expensive, and evaluates design ideas that were previously proposed but not implemented, such as batched EAUG and contiguous demand allocation. The strengths include the use of standard application benchmarks, 10 repetitions with 95% confidence intervals, the decomposition of overheads into page faults, AEXs, EEXITs, and EENTERs, and the candid statement of limitations such as the absence of memory-pressure experiments. The main weakness is that the headline configurations are selected from the same benchmark results used to demonstrate the improvement, and no held-out validation or memory-pressure evaluation is provided, so the external validity of the central 'overheads eliminated' claim is not yet established.

major comments (3)
  1. [§4.2–§4.4, Figs. 7–10] The headline optimized configurations are chosen from the same benchmark results that are used to demonstrate the improvement. Section 4.2 selects 64M pre-allocation 'based on diminishing returns' after inspecting Fig. 6; §4.3 fixes the demand window to 8 or 64 pages after testing those values on the same three workloads; §4.4 fixes the lazy-free thresholds to 5% and 15% in the same way. No held-out workload or independent validation is reported. Because these parameters directly control the space/time trade-off, the central claim that EDMM overheads are 'effectively eliminated' is not yet supported for workloads beyond the three tested. Please provide a sensitivity analysis or a principled, workload-independent rule for setting the parameters, or temper the generality of the claim.
  2. [§4.1–§4.2, Fig. 6] The choice of 64M as the pre-allocation size is not supported by the data presented. Section 4.1 reports that RBench approaches static performance only at 512M, GCBench at 128M, and Redis at 256M, yet §4.2 selects 64M 'based on the diminishing returns of increasing this size.' Neither the 64M data points nor an analysis of diminishing returns is shown in Fig. 6. This parameter is part of every optimized configuration in the paper, so the selection needs to be justified or revised.
  3. [§4.1, §4.3, §4.4] The space-efficiency benefit of EDMM is not evaluated under memory pressure. +pre retains mapped pages, +demand<N> maps ahead, and +lf deliberately keeps freed pages cached; all three trade memory footprint for execution time. The paper explicitly leaves memory-pressure experiments to future work (§4.1), yet the conclusion claims that the optimizations retain EDMM's 'space efficiency gains.' Please add a measurement of peak or steady-state enclave memory footprint for each configuration, ideally under EPC or system memory pressure, or narrow the claim to the no-memory-pressure regime.
minor comments (5)
  1. [Fig. 6] The caption lists +pre(64M) as a plotted configuration, but the panels only show 128M, 256M, and 512M; please clarify whether the 64M data are missing or the caption is stale.
  2. [Title and §4] The title uses 'Adaptive,' but the proposed mechanisms are static configuration options selected offline rather than runtime adaptation; consider rewording the title or adding a discussion of how the parameters would be chosen adaptively in practice.
  3. [§3.2] The text describes a '144-core 2.40 GHz Intel(R) Xeon(R) Platinum 8360Y'; public specifications for that model list 36 cores and 72 threads, so the core count appears to be a typo (possibly a four-socket system).
  4. [§3.3] The sentence 'all other binaries are in writable inside the enclave' should read 'are mapped writable inside the enclave.'
  5. [General] No artifact or availability statement is provided for the Gramine extensions and the patched SGX driver; making these available would materially aid reproducibility.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper reports empirical measurements of an EDMM implementation, and its headline results are evaluations, not derivations from the fitted inputs.

full rationale

This paper is an empirical systems study. It measures enclave loading and execution times for static allocation, basic EDMM, demand allocation, and a series of optimizations on three benchmarks. There is no derivation chain in which an output quantity is defined in terms of an input quantity, and no fitted parameter is renamed as a prediction. The optimizations are concrete system changes (pre-allocation, batching via madvise, contiguous demand allocation, lazy free), and the reported overhead reductions are direct measurements on the same configurations. The authors do select configuration values by inspecting results on the same workloads, such as choosing 64M pre-allocation 'based on the diminishing returns of increasing this size' and testing demand window sizes of 8 and 64 pages and lazy thresholds of 5% and 15%. This is an in-sample tuning concern that limits external validity, but it is not circularity: the paper does not claim to predict held-out performance from these settings, nor does any conclusion reduce by construction to the parameter choices. Self-citations to previous Gramine papers describe the system being modified; they are not used to justify the central performance claims, which are supported by measurements against an independent static-allocation baseline. No uniqueness theorem or load-bearing authority is imported from the authors' prior work. Thus, under the stated circularity criteria, the appropriate finding is no significant circularity.

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

All parameters are engineering knobs. The driver madvise extension is a software interface rather than a postulated entity, so it is not counted as an invented entity.

free parameters (3)
  • pre-allocation size = 64M, 128M, 256M, 512M (64M used in combined configs)
    User-specified initial heap size; the authors pick 64M for later evaluations based on diminishing returns observed in the same figures.
  • contiguous demand allocation window N = 1, 8, and 64 pages
    Amortizes demand-fault cost over N pages; no principled model is given for choosing N, only tested values.
  • lazy free threshold = 5% and 15%
    Maximum freed memory held in cache before unmapping; thresholds are evaluated on the same workloads used for the headline results.
assumptions (3)
  • domain assumption EDMM leaf functions (EAUG, EACCEPT, EMODPR, etc.) and the context-switch costs of adding and removing pages behave as described in the Intel manual and as measured on the test platform.
    The whole cost model in Sections 3.4 through 3.6 rests on this hardware behavior.
  • ad hoc to paper The Linux SGX driver can be extended with a custom madvise ioctl that batches EAUG operations without changing the security or TLB-flush semantics.
    Batch and contiguous demand optimizations require this patch (Sections 4.2 and 4.3); no public patch or commit is provided.
  • domain assumption Applications do not deliberately access munmap-ed memory, so lazy free's non-POSIX behavior is acceptable.
    The paper states that lazy free is not strictly POSIX compliant and assumes such cases are rare (Section 4.4).

how reviews work

0 comments
Cite this review

Pith. "Pith review of Adaptive and Efficient Dynamic Memory Management for Hardware Enclaves." pith.science (2026). https://pith.science/paper/SBR676F4

@misc{pith2026250416251,
  author       = {Pith},
  title        = {Pith review of: Adaptive and Efficient Dynamic Memory Management for Hardware Enclaves},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SBR676F4}},
  note         = {Machine review of arXiv:2504.16251}
}
read the original abstract

The second version of Intel Software Guard Extensions (Intel SGX), or SGX2, adds dynamic management of enclave memory and threads. The first version required the address space and thread counts to be fixed before execution. The Enclave Dynamic Memory Management (EDMM) feature of SGX2 has the potential to lower launch times and overall execution time. Despite reducing the enclave loading time by 28--93%, straightforward EDMM adoption strategies actually slow execution time down by as much as 58%. Using the Gramine library OS as a representative enclave runtime environment, this paper shows how to recover EDMM performance. The paper explains how implementing mutual distrust between the OS and enclave increases the cost of modifying page mappings. The paper then describes and evaluates a series of optimizations on application benchmarks, showing that these optimizations effectively eliminate the overheads of EDMM while retaining EDMM's performance and flexibility gains.

Figures

Figures reproduced from arXiv: 2504.16251 by the authors.

Figure 2
Figure 2. The current system flow for dynamically adding a page to an SGX enclave with EDMM. Trusted software is shaded blue. Compared to allocating a page to a nor￾mal process, this requires an additional context switch, back into the enclave, and that the enclave accepts the new mapping. implements one PAL per supported host platform (e.g., Linux on SGX); the PAL abstracts and encapsulates host￾specific differences, so that… view at source ↗
Figure 4
Figure 4. System flow of creating a new enclave virtual memory mapping via demand allocation, involving five context switches among the untrusted kernel, Gramine’s untrusted runtime, and the enclave. Trusted components are in blue, untrusted in pink. 3.5 Baseline 3: Demand Allocation (edmm+demand) Demand allocation is a standard optimization in memory management. In prior work, Xing et al. [46] propose, but do not implement o… view at source ↗
Figure 5
Figure 5. Benchmarking of three application workloads: (a) RBench; (b) Redis; (c) GCBench, and (d) the numbers of page faults, AEXs, EEXITs, and EENTERs during the GCBench execution. Each set of results is collected on static allocation (sgx1), basic EDMM support (edmm), and EDMM with demand allocation (edmm+demand). Lower is better. After accepting the new mapping, the enclave must again context switch back to the untrusted … view at source ↗
Figures from the paper (5 more)
Figure 6
Figure 6. Figure 6: (Pre-allocation) Benchmarking of three application workloads: (a) RBench; (b) Redis; (c) GCBench, and (d) the numbers of page faults, AEXs, EEXITs, and EENTERs during the GCBench execution. Each set of results is collected on the three baselines (sgx1, edmm, and edmm+d…
Figure 7
Figure 7. Figure 7: (Batch Allocation) Benchmarking of three application workloads: (a) RBench; (b) Redis; (c) GCBench, and (d) the numbers of page faults, AEXs, EEXITs, and EENTERs during the GCBench execution. Each set of results is collected on the three baselines (sgx1, edmm, and edmm…
Figure 8
Figure 8. Figure 8: (Contiguous Demand Allocation) Benchmarking of three application workloads: (a) RBench; (b) Redis; (c) GCBench, and (d) the numbers of page faults, AEXs, EEXITs, and EENTERs during the GCBench execution. Each set of results is collected on the three baselines (sgx1, ed…
Figure 9
Figure 9. Figure 9: The optimized system flow of allocating N new enclave virtual memory mappings (N is a parameter set in the enclave’s configuration) via demand allocation, involving seven context switches among the untrusted kernel, Gramine’s untrusted runtime, and the enclave. Trusted…
Figure 10
Figure 10. Figure 10: (Lazy Free) Benchmarking of three application workloads: (a) RBench; (b) Redis; (c) GCBench, and (d) the numbers of page faults, AEXs, EEXITs, and EENTERs during the GCBench execution. Each set of results is collected on the three baselines (sgx1, edmm, and edmm+deman…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

52 extracted references · 41 canonical work pages

  1. [1]

    Alibaba. 2020. Alibaba Cloud Released Industry’s First Trusted and Virtualized Instance with Support for SGX 2.0 and TPM.https://www.alibabacloud.com/blog/alibaba-cloud- released-industrys-first-trusted-and-virtualized-instance-with- support-for-sgx-2-0-and-tpm_596821. (October 2020)

    work page 2020

  2. [2]

    Alibaba. 2023. Alibaba Cloud, Elastic Compute Services, Instance Type Families, Overview.https://www.alibabacloud .com/help/doc-detail/60576.htm?spm=a2c63.p38356.b99.95 .32ae1160CQKT0I. (August 2023)

    work page 2023

  3. [3]

    AMD. [n. d.]. AMD Secure Encrypted Virtualization (SEV). https://developer.amd.com/sev/. ([n. d.])

    work page

  4. [4]

    AMD. 2020. White PaperAMD SEV-SNP: Strengthening VM Isolationwith Integrity Protection and More.https://ww w.amd.com/system/files/TechDocs/SEV-SNP-strengthening- vm-isolation-with-integrity-protection-and-more.pdf. (2020)

    work page 2020

  5. [5]

    ARM. [n. d.]. ARM Secure IP.https://developer.arm.com/ip- products/security-ip. ([n. d.])

    work page

  6. [6]

    Stillwell, David Goltzsche, David Eyers, Rüdiger Kapitza, Peter Pietzuch, and Christof Fetzer

    Sergei Arnautov, Bohdan Trach, Franz Gregor, Thomas Knauth, Andre Martin, Christian Priebe, Joshua Lind, Di- vya Muthukumaran, Dan O’Keeffe, Mark L. Stillwell, David Goltzsche, David Eyers, Rüdiger Kapitza, Peter Pietzuch, and Christof Fetzer. 2016. SCONE: Secure Linux Contain- ers with Intel SGX. InProceedings of the 12th USENIX Conference on Operating S...

    work page arXiv 2016

  7. [7]

    Andrew Baumann, Marcus Peinado, and Galen Hunt. 2014. Shielding Applications from an Untrusted Cloud with Haven. In11th USENIX Symposium on Operating Systems De- sign and Implementation (OSDI 14). USENIX Association, Broomfield, CO, 267–283.https://www.usenix.org/conferenc e/osdi14/technical-sessions/presentation/baumann

    work page 2014

  8. [9]

    Saba Eskandarian and Matei Zaharia. 2019. ObliDB: Obliv- ious Query Processing for Secure Databases.Proc. VLDB Endow.13, 2 (Oct. 2019), 169–183.https://doi.org/10.14778 /3364324.3364331

    arXiv 2019

Show all 52 references
  1. [10]

    Ben Fisch, Dhinakaran Vinayagamurthy, Dan Boneh, and Sergey Gorbunov. 2017. IRON: Functional Encryption Using Intel SGX. InProceedings of the 2017 ACM SIGSAC Con- ference on Computer and Communications Security (CCS ’17). Association for Computing Machinery, New York, NY, USA,...

    2017

  2. [11]

    Johannes Götzfried, Moritz Eckert, Sebastian Schinzel, and Tilo Müller. 2017. Cache Attacks on Intel SGX. InProceed- ings of the 10th European Workshop on Systems Security (EuroSec’17). Association for Computing Machinery, New York, NY, USA, Article 2, 6 pages.https://doi.org/...

    2017

  3. [12]

    Marcus Hähnel, Weidong Cui, and Marcus Peinado. 2017. High-Resolution Side Channels for Untrusted Operating Systems. In2017 USENIX Annual Technical Conference (USENIX ATC 17). USENIX Association, Santa Clara, CA, 299–312.https://www.usenix.org/conference/atc17/technical- sessi...

    2017

  4. [13]

    IBM. 2020. IBM Cloud Data Shield Now Generally Available. https://www.ibm.com/blog/announcement/ibm-cloud-data- shield-now-generally-available/. (April 2020)

    2020

  5. [14]

    IBM. 2023. Provisioning a bare metal server with Intel® Software Guard Extension architecture.https://cloud.ibm. com/docs/bare-metal?topic=bare-metal-bm-server-provision- sgx. (January 2023)

    2023

  6. [15]

    Intel. 2021. Intel&Reg; Hardware Shield–Intel&Reg; Total Memory Encryption.https://www.intel.com/content/dam/ www/central-libraries/us/en/documents/white-paper-intel- tme.pdf. (2021)

    2021

  7. [16]

    Intel. 2022. Asynchronous Enclave Exit Notify and the EDECCSSA User Leaf Function.https://cdrdv2.intel.c om/v1/dl/getContent/736463?explicitVersion=true. (2022)

    2022

  8. [17]

    Intel. 2022. Intel Trust Domain Extensions.https://cdrdv2.i ntel.com/v1/dl/getContent/690419. (2022)

    2022

  9. [18]

    Kyungtae Kim, Chung Hwan Kim, Junghwan "John" Rhee, Xiao Yu, Haifeng Chen, Dave (Jing) Tian, and Byoungyoung Lee. 2020. Vessels: Efficient and Scalable Deep Learning Prediction on Trusted Processors. InProceedings of the 11th ACM Symposium on Cloud Computing (SoCC ’20). Associ...

    2020

  10. [19]

    SeongminKim,JuhyengHan,JaehyeongHa,TaesooKim,and Dongsu Han. 2017. Enhancing Security and Privacy of Tor’s Ecosystem by Using Trusted Execution Environments. In 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI 17). USENIX Association, Boston, MA, 145–...

    2017

  11. [20]

    Taehoon Kim, Joongun Park, Jaewook Woo, Seungheun Jeon, and Jaehyuk Huh. 2019. ShieldStore: Shielded In-Memory Key-Value Storage with SGX. InProceedings of the Four- teenth EuroSys Conference 2019 (EuroSys ’19). Association for Computing Machinery, New York, NY, USA, Article 1...

    2019

  12. [21]

    Asokan, Andrew Simpson, and Robin Ankele

    Kubilay Ahmet Küçük, Andrew Paverd, Andrew Martin, N. Asokan, Andrew Simpson, and Robin Ankele. 2016. Exploring the Use of Intel SGX for Secure Many-Party Applications. InProceedings of the 1st Workshop on System Software for Trusted Execution (SysTEX ’16). Association for Com...

    2016

  13. [23]

    Haonan Li, Weijie Huang, Mingde Ren, Hongyi Lu, Zhenyu Ning, Heming Cui, and Fengwei Zhang. 2022. A Novel Mem- ory Management for RISC-V Enclaves. InProceedings of the 10th International Workshop on Hardware and Architectural Support for Security and Privacy (HASP ’21). Associ...

    2022

  14. [24]

    Ximing Liu, Wenwen Wang, Lizhi Wang, Xiaoli Gong, Ziyi Zhao, and Pen-Chung Yew. 2020. Regaining Lost Seconds: Efficient Page Preloading for SGX Enclaves. InProceedings of the 21st International Middleware Conference (Middleware ’20). Association for Computing Machinery, New Yo...

    2020

  15. [25]

    Frank McKeen, Ilya Alexandrovich, Ittai Anati, Dror Caspi, Simon Johnson, Rebekah Leslie-Hurd, and Carlos Rozas

  16. [26]

    Rozas, Hisham Shafi, Vedvyas Shanbhogue, and Uday R

    Frank McKeen, Ilya Alexandrovich, Alex Berenzon, Car- los V. Rozas, Hisham Shafi, Vedvyas Shanbhogue, and Uday R. Savagaonkar. 2013. Innovative Instructions and Software Model for Isolated Execution. InProceedings of the 2nd International Workshop on Hardware and Architec- tur...

    2013

  17. [27]

    Microsoft. 2023. DCsv3 and DCdsv3-series.https://learn.micr osoft.com/en-us/azure/virtual-machines/dcv3-series. (January 2023)

    2023

  18. [28]

    Pratyush Mishra, Rishabh Poddar, Jerry Chen, Alessandro Chiesa, and Raluca Popa. 2018. Oblix: An Efficient Oblivious Search Index. 279–296.https://doi.org/10.1109/SP.2018.0004 5

    2018

  19. [29]

    Meni Orenbach, Andrew Baumann, and Mark Silberstein

  20. [30]

    Meni Orenbach, Pavel Lifshits, Marina Minkin, and Mark Silberstein. 2017. Eleos: ExitLess OS Services for SGX En- claves. InProceedings of the Twelfth European Conference on Computer Systems (EuroSys 17). 238–253

    2017

  21. [31]

    Meni Orenbach, Yan Michalevsky, Christof Fetzer, and Mark Silberstein. 2019. CoSMIX: A Compiler-based System for Secure Memory Instrumentation and Execution in Enclaves. In2019 USENIX Annual Technical Conference (USENIX ATC 19). USENIX Association, Renton, WA, 555–570.https: /...

    2019

  22. [32]

    Samuele Pedroni, Hans Boehm, John Ellis, and Pete Kovac

  23. [33]

    Rafael Pires, Marcelo Pasin, Pascal Felber, and Christof Fetzer. 2016. Secure Content-Based Routing Using Intel Soft- ware Guard Extensions. InProceedings of the 17th Interna- tional Middleware Conference (Middleware ’16). Association for Computing Machinery, New York, NY, USA...

    2016

  24. [34]

    Rishabh Poddar, Chang Lan, Raluca Ada Popa, and Sylvia Ratnasamy. 2018. Safebricks: Shielding Network Functions in the Cloud. InProceedings of the 15th USENIX Conference on Networked Systems Design and Implementation (NSDI’18). USENIX Association, USA, 201–216

    2018

  25. [35]

    Christian Priebe, Kapil Vaswani, and Manuel Costa. 2018. EnclaveDB – A Secure Database using SGX. InOakland. IEEE.https://www.microsoft.com/en-us/research/publicatio n/enclavedb-a-secure-database-using-sgx/

    2018

  26. [36]

    Redis. 2023. Redis benchmark.https://redis.io/docs/manage ment/optimization/benchmarks/. (2023)

    2023

  27. [37]

    FelixSchuster,ManuelCosta,CédricFournet, ChristosGkant- sidis, Marcus Peinado, Gloria Mainar-Ruiz, and Mark Russi- novich. 2015. VC3: Trustworthy data analytics in the cloud using SGX. In2015 IEEE Symposium on Security and Pri- vacy (S&P 15). IEEE, 38–54

    2015

  28. [38]

    Youren Shen, Hongliang Tian, Yu Chen, Kang Chen, Runji Wang, Yi Xu, Yubin Xia, and Shoumeng Yan. 2020. Oc- clum: Secure and efficient multitasking inside a single enclave of Intel SGX. InProceedings of the Twenty-Fifth Interna- tional Conference on Architectural Support for Pr...

    2020

  29. [39]

    Meysam Taassori, Ali Shafiee, and Rajeev Balasubramonian

  30. [40]

    Chia-Che Tsai, Kumar Saurabh Arora, Nehal Bandi, Bhushan Jain,WilliamJannen,JitinJohn,HarryA.Kalodner,Vrushali Kulkarni, Daniela Oliveira, and Donald E. Porter. 2014. Co- operation and Security Isolation of Library OSes for Multi- Process Applications. InEuroSys

    2014

  31. [41]

    Porter, and Mona Vij

    Chia-Che Tsai, Donald E. Porter, and Mona Vij. 2017. Graphene-SGX: A Practical Library OS for Unmodified Appli- cations on SGX. In2017 USENIX Annual Technical Confer- ence (USENIX ATC 17). USENIX Association, Santa Clara, CA, 645–658.https://www.usenix.org/conference/atc17/tec...

    2017

  32. [42]

    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. InUSENIX Security

    2020

  33. [43]

    InProceedings of the Twenty-Third International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS ’18)

    VAULT: Reducing Paging Overheads in SGX with Efficient Integrity Verification Structures. InProceedings of the Twenty-Third International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS ’18). Association for Computing Machinery, New ...

    doi

  34. [44]

    Jo Van Bulck, Frank Piessens, and Raoul Strackx. 2017. SGX- Step: A practical attack framework for precise enclave execu- tion control. InProceedings of the 2nd Workshop on System Software for Trusted Execution. 1–6

    2017

  35. [45]

    Jo Van Bulck, Nico Weichbrodt, Rüdiger Kapitza, Frank Piessens, and Raoul Strackx. 2017. Telling your secrets without page faults: Stealthy page table-based attacks on enclaved execution. In26th {USENIX} Security Symposium ({USENIX}Security 17). 1041–1056

    2017

  36. [46]

    Bin (Cedric) Xing, Mark Shanahan, and Rebekah Leslie- Hurd. 2016. Intel® Software Guard Extensions (Intel® SGX) Software Support for Dynamic Memory Management Inside an Enclave. InProceedings of the Hardware and Architectural Support for Security and Privacy 2016 (HASP 2016). ...

    2016

  37. [47]

    Simon Urbanek and Philippe Grosjean. 2008. R Benchmark. https://mac.r-project.org/benchmarks/. (2008)

    2008

  38. [48]

    Yahoo. 2019. Yahoo! Cloud Serving Benchmark.https: //ycsb.site. (2019)

    2019

  39. [49]

    Jason Zhijingcheng Yu, Shweta Shinde, Trevor E Carlson, and Prateek Saxena. 2022. Elasticlave: An efficient memory model for enclaves. In31st USENIX Security Symposium 14 (USENIX Security 22). 4111–4128

    2022

  40. [50]

    ZDNet. 2020. Cloud security: Microsoft Azure’s SGX VMs hit GA, Google’s Shielded VM is now default.https://www. zdnet.com/article/cloud-security-microsoft-azures-sgx-vms- hit-ga-googles-shielded-vm-is-now-default/. (April 2020). 15

    2020

  41. [51]

    Yuanzhong Xu, Weidong Cui, and Marcus Peinado. 2015. Controlled-Channel Attacks: Deterministic Side Channels for Untrusted Operating Systems. InProceedings of the 36th IEEE Symposium on Security and Privacy (Oakland)

    2015

  42. [2016]

    InProceedings of the Hardware and Architectural Support for Security and Privacy 2016 (HASP 2016)

    Intel&Reg; Software Guard Extensions (Intel&Reg; SGX) Support for Dynamic Memory Management Inside an Enclave. InProceedings of the Hardware and Architectural Support for Security and Privacy 2016 (HASP 2016). ACM, New York, NY, USA, Article 10, 9 pages.https://doi.org/10 .114...

    2016

  43. [2018]

    GCBench.https://github.com/mozillazg/pypy/blob/407 95dcad7e1b0be53d2f95a94f0278086d2d448/rpython/translat or/goal/gcbench.py. (2018)

    2018

  44. [2020]

    InProceedings of the Fifteenth European Con- ference on Computer Systems (EuroSys ’20)

    Autarky: Closing Controlled Channels with Self-Paging Enclaves. InProceedings of the Fifteenth European Con- ference on Computer Systems (EuroSys ’20). Association for Computing Machinery, New York, NY, USA, Article 7, 16 pages.https://doi.org/10.1145/3342195.3387541

Pith tools

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