Pith. sign in

REVIEW 3 major objections 6 minor 2 cited by

SGX-LKL: Securing the Host OS Interface for Trusted Execution

T0 review · 3 major / 6 minor · reviewed 2026-08-14 · deepseek-v4-flash

Pith's one-line read SGX-LKL runs unmodified Linux binaries inside SGX enclaves behind a 7-call, encrypted, and access-pattern-blind host interface.

desk verdict Solid systems artifact with a real design idea, but the 'oblivious host interface' claim overreaches: the disk obliviousness proof is missing and the interface count is 8, not 7, on the evaluated hardware. read the letter →

arxiv 1908.11143 v3 pith:L64KPSYZ submitted 2019-08-29 cs.OS cs.CR

classification cs.OScs.CR
keywords IntelSGXtrustedexecutionenvironmentlibraryOShostinterfaceobliviousI/Odiskaccesspatternconfidentialcomputingnetworktrafficpadding
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

SGX-LKL is a runtime system that runs ordinary Linux binaries inside Intel SGX enclaves while reducing what the untrusted host operating system can observe or tamper with to a seven-call interface. The paper argues that this interface is minimal (all POSIX functionality is supplied by a Linux library OS inside the enclave), protected (every disk block and network packet is encrypted and integrity-checked), and oblivious (host calls are issued in fixed batches, disk blocks are periodically shuffled, and network traffic is padded to a constant rate). If the account is right, a cloud tenant can protect a workload such as TensorFlow training from the host OS without modifying the application, at a cost of roughly 14-21% overhead in software mode and 1.5x-3.1x on current SGX hardware for workloads that fit in enclave memory. The significance is that the traditional system-call interface, a standing source of confidentiality leaks and integrity attacks, is replaced by a narrow boundary whose parameters are designed to be meaningless to the host.

What carries the argument

The central mechanism is a deliberately minimal host interface, plus the in-enclave functionality that makes that minimality safe. SGX-LKL's interface exposes seven calls: disk_read and disk_write for 4 KB blocks, net_read and net_write for MTU-sized frames, net_poll for readiness events, forward_signal for hardware exceptions, and time_read for clock values. Storage obliviousness is carried by treating the in-enclave page cache as a private shelter, as in square-root ORAM, and periodically running a k-oblivious shuffle, a random permutation of all disk blocks that is safe when some of them are already held in private memory, in which file blocks are swapped with randomly located donor-file blocks according to a Fisher-Yates permutation, using the ext4 move_ext ioctl to update the block mapping. Network obliviousness is carried by fixed-size packets plus per-peer dummy traffic rate-limited with Linux traffic shaping, so the host observes a constant bit rate.

What would settle it

Run a workload whose working set exceeds the in-enclave page cache while recording the sequence of disk_read offsets observed by the host. If the same encrypted block offset appears twice between two shuffle events, the workload re-read a block without a shuffle, and the host can infer the re-access; that observation would falsify the claimed disk obliviousness. The paper gives no bound on cache size, eviction rate, or shuffle trigger that would prevent this.

Watch

Extended reading notes

Core claim

The paper's claim is that a secure TEE runtime does not need to protect individual system calls one by one; it needs to stop delegating OS functionality entirely. SGX-LKL ports the Linux Kernel Library into the enclave, so file systems, the TCP/IP stack, threading, signals, and memory management all run inside the trusted boundary. What remains outside are four I/O primitives (block read/write and packet read/write), a poll call, a signal forwarding call, and a time read. Disk data is encrypted and integrity-protected with the Linux device-mapper stack, and the ext4 image's block mapping is re-randomised with a k-oblivious shuffle, so the host sees reads and writes to random-looking offsets. Network data is protected by a Wireguard VPN over fixed-size packets shaped to a constant bit rate. With these mechanisms, the paper reports unmodified TensorFlow training at 14-21% overhead over native in emulated enclaves, and PARSEC workloads on SGX hardware at 1.5x slowdown without oblivious calls and 3.1x with them.

Load-bearing premise

The whole disk-privacy claim rests on the idea that between two shuffles no block is ever read from disk twice, because the page cache holds every accessed block until the next shuffle; the paper does not specify what forces a shuffle before an eviction could violate that.

Editorial extensions

If this is right

  • If the central claim holds, a tenant can deploy unmodified Linux binaries on an untrusted cloud host without exposing file names, file sizes, directory structure, or disk access patterns to the host OS.
  • The host interface becomes a fixed-rate stream of fixed-size encrypted blocks and packets, so the host cannot distinguish one application phase from another by call timing or by block offsets.
  • Protected network communication is available to applications that do not implement their own encryption: the enclave-side VPN layer supplies confidentiality and integrity transparently.
  • The performance cost is workload-dependent and concentrated in I/O-heavy or memory-heavy cases such as AlexNet training and large-footprint PARSEC benchmarks; CPU-bound models run close to native speed.
  • Attestation and key provisioning are folded into the same workflow, so a service provider can ship an encrypted disk image and release its keys only to an enclave whose measurement is verified.

Reading between the lines

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

  • Not claimed by the paper: the page-cache invariant needs a concrete trigger; one extension is to force a shuffle whenever an evicted block could be re-requested, and to test this under adversarial access patterns.
  • Not claimed by the paper: if a workload repeatedly reaccesses a block that was evicted between shuffles, the host sees the same offset twice; a stress test with a working set near the page-cache size would show whether the guarantee holds in practice.
  • Not claimed by the paper: the same design could be lifted to other trusted-execution hardware that supports in-enclave memory management, since the host interface only assumes fixed-size encrypted blocks and packets rather than SGX-specific instructions beyond attestation.
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 / 6 minor

Summary. The paper presents SGX-LKL, a TEE runtime system that runs unmodified Linux binaries inside Intel SGX enclaves. SGX-LKL ports the Linux Kernel Library (LKL) into the enclave, providing a full POSIX interface to applications, and exposes to the host only a small set of low-level calls: disk block reads/writes, network packet reads/writes, network polling, signal forwarding, and time reads. The host interface is claimed to be minimal (7 calls), protected (encryption and integrity via device-mapper targets and WireGuard), and oblivious (batched, padded calls; disk block shuffling; constant-rate network traffic). The evaluation reports TensorFlow training overheads of 14-21% in software mode and 1.5x-3.1x on SGX hardware for PARSEC workloads that fit in enclave memory.

Significance. This is a substantial systems contribution. The key idea of designing the host interface bottom-up around minimality, protection, and obliviousness, rather than retrofitting a library OS, is well executed, and the resulting system is open source. The evaluation is careful to separate software-mode from SGX-hardware-mode effects, and the overhead numbers for TensorFlow (14-21% in software mode) are encouraging. The paper's strongest assets are its concrete engineering (dm-crypt/dm-verity/dm-integrity, WireGuard, LKL integration) and the systematic parameter analysis in Table 1. If the obliviousness guarantee can be rigorously established, this would be a valuable reference design for TEE runtimes.

major comments (3)
  1. [Section 5.1] The disk-obliviousness construction is a square-root ORAM variant in which the in-enclave page cache serves as the shelter, and the guarantee depends on the invariant that 'between shuffles, SGX-LKL reads a block at most once' (Section 1) by relying on the page cache. The paper asserts this invariant but provides no eviction bound, no shuffle trigger, and no proof. The LKL page cache is an ordinary LRU cache; for any workload whose working set exceeds the cache, blocks will be evicted and later re-accessed, issuing the same disk offset twice to the host before any shuffle occurs. Section 6 states that a 'large page cache size' is used but does not quantify it relative to the workload, and the hardware-mode PARSEC results in Figure 6 show severe slowdowns for canneal and fluidanimate attributed to EPC paging, which indicates that eviction and re-access are realistic. Without a bound on the number of distinct blocks accessed between shuffles and a guaranteed shuffle-before-eviction mechanism, the claimed obliviousness of the host interface is not established.
  2. [Table 2 and Section 3.2] The abstract and Table 2 claim a minimal interface with 7 host calls, but Section 3.2 describes an additional mem_protect() call used as a workaround for SGX version 1. Because the evaluation in Section 6 runs on SGX v1 hardware, the actual host interface for the evaluated system has 8 calls, and the mem_protect() call passes an address range to the host, a parameter type that Table 1 reports as absent for SGX-LKL. The minimality claim and the parameter analysis should be updated to account for mem_protect(), or the abstract should be qualified to state that the 7-call claim applies to SGX v2.
  3. [Section 5.1, Algorithm 1] The shuffle procedure is described at the block level, but the mechanism that determines when a shuffle is triggered and how the page-cache invariant is enforced is absent. The text states that 'SGX-LKL must obliviously reshuffle blocks before continuing execution' if evicted blocks are requested, but it does not specify how the system detects pending eviction, what maximum number of accesses per epoch is permitted, or how the cache size relates to the disk size. In addition, the assumption that 'the list of files to shuffle can be obtained from a trace of opened files' requires the enclave to maintain or observe such a trace, and the confidentiality of that trace (e.g., which files the application opened) is not analyzed. Without these details, the construction is not a complete specification of an oblivious disk interface.
minor comments (6)
  1. [Section 5.1] There is an unresolved cross-reference in the sentence 'We focus on the disk (§5.1) and network (§??) I/O host calls', which should point to the correct subsection for network I/O.
  2. [Figure 6] The label 'fuid animate' should be 'fluidanimate'.
  3. [Section 6] The phrase 'a large page cache size' is not quantified; the page cache size should be reported relative to the workload working sets so that readers can assess whether the oblivious-mode results actually satisfy the no-eviction invariant.
  4. [Section 5.2] The claim that time_read is oblivious because the SGX-LKL scheduler accesses time on every context switch is not quantified; a workload that causes few context switches could still reveal a low vDSO read rate to the host, so a bound or empirical validation of this argument would be helpful.
  5. [Section 5.1] The parameter k in 'k-oblivious shuffle' is not defined; the paper should state the relationship between k, the page cache size, and the number of disk blocks n.
  6. [Table 1] The security comparison in Table 1 relies entirely on the authors' own parameter classification; an independent adversarial analysis, or at least a more detailed justification of the classification choices, would strengthen the claims made from this table.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the construction and benchmarks are self-contained, and the disk-obliviousness concern is an unproven security invariant rather than a derivation-from-inputs circularity.

full rationale

SGX-LKL builds its claimed contributions from independent components: LKL provides the in-enclave POSIX layer, the 7-call host interface is a design choice rather than a fitted or predicted quantity, dm-crypt/Wireguard provide the protected I/O paths, and the square-root-ORAM-style disk shuffling is adapted from external prior work (Goldreich and Ostrovsky; Patel et al.). The performance evaluation compares against native execution without fitting parameters and then renaming them as predictions, and the central 'minimal, protected, oblivious' claim is not derived from a self-citation chain. The Table 1 parameter taxonomy is an original analysis tool, not a theorem imported from the authors' prior work. The one substantive weakness, that the disk-obliviousness guarantee depends on the unproven invariant that evicted blocks are never re-accessed before a shuffle, is a correctness and security-evidence gap, not a circularity: the paper does not define obliviousness in terms of the invariant, nor does it fit a parameter and then predict the same parameter. Therefore no circular step meeting the quoted-evidence standard is present.

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

SGX-LKL introduces no new physical entities; the 'donor files' and 'dummy packets' are mechanisms built from existing file and network abstractions. The central claim rests on standard math, standard cryptographic and kernel components, and one unproven workload assumption about page-cache behavior between shuffles.

free parameters (3)
  • batch interval t = 0.1 ms
    Section 5.1: 'The timing parameter t must be tuned for good performance because applications issue system calls at different rates... In our experiments, we use t = 0.1 ms.' This hand-set value determines the trade-off between dummy-call overhead and application progress; no sensitivity analysis is reported.
  • network constant bitrate = 200 Mbps per peer
    Section 6.1: oblivious network I/O uses 'a constant rate of 200 Mbps per peer'. The rate must be high enough to carry real traffic and low enough to bound overhead; the paper does not analyze this trade-off.
  • page cache size for oblivious mode = large (unquantified)
    Section 6: 'When using the oblivious host interface, we randomise the disk image and use a large page cache size.' The disk-obliviousness invariant in Section 5.1 requires the cache to hold all previously accessed blocks between shuffles; the size and eviction behavior are not reported.
assumptions (6)
  • standard math Fisher-Yates shuffle produces a uniformly random permutation.
    Algorithm 1, line 11 uses Fisher-Yates to generate the new logical-to-physical mapping; uniform randomness is needed for the k-oblivious shuffle's indistinguishability argument.
  • domain assumption dm-crypt and dm-integrity (AES-GCM) provide confidentiality and integrity for disk blocks, and WireGuard provides authenticated encryption and replay protection for network packets.
    Sections 4.1 and 4.2 rely on these standard kernel and cryptographic components; the paper does not analyze their security properties or failure modes.
  • domain assumption Microarchitectural side channels (Spectre, Foreshadow, ZombieLoad, cache attacks) and TEE implementation flaws are excluded from the threat model.
    Section 2.2 explicitly excludes them. If an adversary can use such channels, the host-interface security goal is insufficient; this is a scoping assumption rather than an internal inconsistency.
  • ad hoc to paper Between shuffles, no disk block is read more than once because the in-enclave page cache holds all previously accessed blocks.
    Section 5.1: 'Between shuffles, SGX-LKL reads a block at most once by relying on the in-enclave page cache.' No mechanism guarantees this for arbitrary workloads; if it fails, repeated offsets are visible to the host.
  • ad hoc to paper The list of files to shuffle can be obtained from a trace of opened files, or all files on the disk can be shuffled.
    Algorithm 1 preamble: 'To protect a single application workload, this list can be obtained from a trace of opened files; otherwise all files on the disk can be considered.' Prior knowledge of the file-access set is assumed.
  • domain assumption Hardware exceptions inside SGX v1 enclaves cause an exit to the host and are observable by the host.
    Sections 3.2 and 5.2 rely on this to justify the forward_signal call and admit that exception occurrences cannot be hidden.

how reviews work

0 comments
Cite this review

Pith. "Pith review of SGX-LKL: Securing the Host OS Interface for Trusted Execution." pith.science (2026). https://pith.science/paper/L64KPSYZ

@misc{pith2026190811143,
  author       = {Pith},
  title        = {Pith review of: SGX-LKL: Securing the Host OS Interface for Trusted Execution},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/L64KPSYZ}},
  note         = {Machine review of arXiv:1908.11143}
}
read the original abstract

Hardware support for trusted execution in modern CPUs enables tenants to shield their data processing workloads in otherwise untrusted cloud environments. Runtime systems for the trusted execution must rely on an interface to the untrusted host OS to use external resources such as storage, network, and other functions. Attackers may exploit this interface to leak data or corrupt the computation. We describe SGX-LKL, a system for running Linux binaries inside of Intel SGX enclaves that only exposes a minimal, protected and oblivious host interface: the interface is (i) minimal because SGX-LKL uses a complete library OS inside the enclave, including file system and network stacks, which requires a host interface with only 7 calls; (ii) protected because SGX-LKL transparently encrypts and integrity-protects all data passed via low-level I/O operations; and (iii) oblivious because SGX-LKL performs host operations independently of the application workload. For oblivious disk I/O, SGX-LKL uses an encrypted ext4 file system with shuffled disk blocks. We show that SGX-LKL protects TensorFlow training with a 21% overhead.

Figures

Figures reproduced from arXiv: 1908.11143 by the authors.

Figure 1
Figure 1. SGX-LKL architecture takes an offset into the block device and a pointer buf to a buffer; for network I/O, net_read() and net_write() receive and send fixed-size network packets using buffer buf. Events. A net_poll() call passes an eventmask to the host with the network events that SGX-LKL is waiting for. The call blocks until network packets are available to be read or outgoing packets can be sent. It returns which… view at source ↗
Figure 2
Figure 2. Deployment workflow for SGX-LKL SGX-LKL addresses these issues as part of three phases: (i) application provisioning, (ii) remote attestation and (iii) se￾cret provisioning [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗
Figure 3
Figure 3. Training throughput with TensorFlow 1 10 100 1000 10000 AlexNet ImageNet AlexNet CIFAR -10 ResNet -34 ResNet -50 ResNet -101 Throughput (Images/sec; logscale) Native SGX-LKL (sim) SGX-LKL (sim+enc/int) SGX-LKL (sim+obliv) [PITH_FULL_IMAGE:figures/full_fig_p010_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Inference throughput with TensorFlow experiments are executed with and without disk encryption and oblivious host calls. To avoid SGX paging effects, we run in software mode with an enclave size of 12.5 GB. In [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]
Figure 5
Figure 5. Figure 5: Distributed training throughput with TensorFlow [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]
Figure 7
Figure 7. Figure 7: Disk performance with encryption/integrity protection [PITH_FULL_IMAGE:figures/full_fig_p011_7.png]
Figure 8
Figure 8. Figure 8: Network I/O throughput for different buffer sizes [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. LURK-T: Limited Use of Remote Keys With Added Trust in TLS 1.3

    cs.CR 2025-05 conditional novelty 6.0 of 10

    LURK-T is a TLS 1.3 server delegation design that isolates long-term credentials in a TEE-backed crypto service while keeping the client-facing TLS protocol unchanged.

  2. TEE-based Key-Value Stores: a Survey

    cs.CR 2025-01 conditional novelty 3.0 of 10

    A survey that categorizes SGX-based trusted key-value stores into reusable design modules and classifies them by data structure, security, and communication strategies.

Reference graph

Works this paper leans on

115 extracted references · 77 canonical work pages · cited by 2 Pith papers

  1. [1]

    Tucker, Vijay Vasudevan, Pete Warden, Martin Wicke, Yuan Yu, and Xiaoqiang Zheng

    Martín Abadi, Paul Barham, Jianmin Chen, Zhifeng Chen, Andy Davis, Jeffrey Dean, Matthieu Devin, San- jay Ghemawat, Geoffrey Irving, Michael Isard, Man- junath Kudlur, Josh Levenberg, Rajat Monga, Sherry Moore, Derek Gordon Murray, Benoit Steiner, Paul A. Tucker, Vijay Vasudevan, Pete Warden, Martin Wicke, Yuan Yu, and Xiaoqiang Zheng. Tensorflow: A sys- t...

  2. [2]

    OBLIVIATE: A Data Oblivious Filesystem for Intel SGX

    Adil Ahmad, Kyungtae Kim, Muhammad Ihsanulhaq Sarfaraz, and Byoungyoung Lee. OBLIVIATE: A Data Oblivious Filesystem for Intel SGX. In Symposium on Network and Distributed System Security (NDSS), 2018

  3. [3]

    Security and Privacy Issues in Wireless Sen- sor Networks for Healthcare Applications

    Moshaddique Al Ameen, Jingwei Liu, and Kyungsup Kwak. Security and Privacy Issues in Wireless Sen- sor Networks for Healthcare Applications. Journal of medical systems, 36(1):93–101, 2012

  4. [4]

    AMD Secure Encrypted Virtualization (SEV)

    AMD. AMD Secure Encrypted Virtualization (SEV). https://developer.amd.com/sev/. Last accessed: August 7, 2019

  5. [5]

    Cloud Computing: A New Vector for Cyber Attacks

    Apriorit. Cloud Computing: A New Vector for Cyber Attacks. https://www.apriorit.com/dev-blog/ 523-cloud-computing-cyber-attacks . Last ac- cessed: August 7, 2019

  6. [6]

    Technologies TrustZone for Cortex-A

    ARM. Technologies TrustZone for Cortex-A. https://www.arm.com/why-arm/technologies/ trustzone-for-cortex-a/tee-reference- documentation. Last accessed: August 7, 2019

  7. [7]

    Still- well, David Goltzsche, Dave Eyers, Rüdiger Kapitza, Peter R

    Sergei Arnautov, Bohdan Trach, Franz Gregor, Thomas Knauth, Andre Martin, Christian Priebe, Joshua Lind, Divya Muthukumaran, Dan O’Keeffe, Mark L. Still- well, David Goltzsche, Dave Eyers, Rüdiger Kapitza, Peter R. Pietzuch, and Christof Fetzer. SCONE: Secure Linux Containers With Intel SGX. In 12th USENIX Symposium on Operating Systems Design and Imple- ...

  8. [8]

    AnoA: A Framework for Analyzing Anonymous Communica- tion Protocols

    Michael Backes, Aniket Kate, Praveen Manoharan, Se- bastian Meiser, and Esfandiar Mohammadi. AnoA: A Framework for Analyzing Anonymous Communica- tion Protocols. In 2013 IEEE 26th Computer Security Foundations Symposium, pages 163–178, 2013

Show all 115 references
  1. [9]

    Shielding Applications from an Untrusted Cloud with Haven

    Andrew Baumann, Marcus Peinado, and Galen Hunt. Shielding Applications from an Untrusted Cloud with Haven. In Proceedings of the 11th USENIX Confer- ence on Operating Systems Design and Implementa- tion, OSDI, pages 267–283, 2014

  2. [10]

    The PARSEC Benchmark Suite: Character- ization and Architectural Implications

    Christian Bienia, Sanjeev Kumar, Jaswinder Pal Singh, and Kai Li. The PARSEC Benchmark Suite: Character- ization and Architectural Implications. In Proceedings 12 of the 17th International Conference on Parallel Archi- tectures and Compilation Techniques, October 2008

  3. [11]

    The guard’s dilemma: Efficient code-reuse attacks against intel SGX

    Andrea Biondo, Mauro Conti, Lucas Davi, Tommaso Frassetto, and Ahmad-Reza Sadeghi. The guard’s dilemma: Efficient code-reuse attacks against intel SGX. In 27th USENIX Security Symposium, USENIX Security, pages 1213–1227, 2018

  4. [12]

    Prochlo: Strong Privacy for Analytics in the Crowd

    Andrea Bittau, Úlfar Erlingsson, Petros Maniatis, Ilya Mironov, Ananth Raghunathan, David Lie, Mitch Rudominer, Ushasree Kode, Julien Tinnes, and Bern- hard Seefeld. Prochlo: Strong Privacy for Analytics in the Crowd. In Proceedings of the 26th Symposium on Operating Systems P...

  5. [13]

    Understanding the Linux Kernel

    Daniel P Bovet and Marco Cesati. Understanding the Linux Kernel. OReilly & Associates. Inc. October 2000, 2002

  6. [14]

    DR.SGX: Hardening SGX Enclaves against Cache Attacks with Data Location Randomization

    Ferdinand Brasser, Srdjan Capkun, Alexandra Dmitrienko, Tommaso Frassetto, Kari Kostiainen, Urs Müller, and Ahmad-Reza Sadeghi. DR.SGX: Hardening SGX Enclaves against Cache Attacks with Data Location Randomization. CoRR, abs/1709.09917, 2017

  7. [15]

    Software grand exposure: SGX cache attacks are practical

    Ferdinand Brasser, Urs Müller, Alexandra Dmitrienko, Kari Kostiainen, Srdjan Capkun, and Ahmad-Reza Sadeghi. Software grand exposure: SGX cache attacks are practical. In 11th USENIX Workshop on Offensive Technologies, WOOT, 2017

  8. [16]

    Leakage-Abuse Attacks Against Search- able Encryption

    David Cash, Paul Grubbs, Jason Perry, and Thomas Ristenpart. Leakage-Abuse Attacks Against Search- able Encryption. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communica- tions Security, pages 668–679, 2015

  9. [17]

    Dm-x: Pro- tecting V olume-level Integrity for Cloud V olumes and Local Block Devices

    Anrin Chakraborti, Bhushan Jain, Jan Kasiak, Tao Zhang, Donald Porter, and Radu Sion. Dm-x: Pro- tecting V olume-level Integrity for Cloud V olumes and Local Block Devices. In Proceedings of the 8th Asia- Pacific Workshop on Systems, APSys, pages 16:1–16:7, 2017

  10. [18]

    The dining cryptographers problem: Unconditional sender and recipient untraceability

    David Chaum. The dining cryptographers problem: Unconditional sender and recipient untraceability. J. Cryptology, 1(1):65–75, 1988

  11. [19]

    The Dining Cryptographers Problem: Unconditional Sender and Recipient Untraceability

    David Chaum. The Dining Cryptographers Problem: Unconditional Sender and Recipient Untraceability. Journal of cryptology, 1(1):65–75, 1988

  12. [20]

    Iago At- tacks: Why the System Call API is a Bad Untrusted RPC Interface

    Stephen Checkoway and Hovav Shacham. Iago At- tacks: Why the System Call API is a Bad Untrusted RPC Interface. In Proceedings of the Eighteenth In- ternational Conference on Architectural Support for Programming Languages and Operating Systems, AS- PLOS, pages 253–264, 2013

  13. [21]

    Perceived In- formation Security, Financial Liability and Consumer Trust in Electronic Commerce Transactions

    Ramnath K Chellappa and Paul A Pavlou. Perceived In- formation Security, Financial Liability and Consumer Trust in Electronic Commerce Transactions. Logistics Information Management, 15(5/6):358–368, 2002

  14. [22]

    Racing in Hyperspace: Closing Hyper-Threading Side Channels on SGX with Con- trived Data Races

    Guoxing Chen, Wenhao Wang, Tianyu Chen, Sanchuan Chen, Yinqian Zhang, XiaoFeng Wang, Ten-Hwang Lai, and Dongdai Lin. Racing in Hyperspace: Closing Hyper-Threading Side Channels on SGX with Con- trived Data Races. In 2018 IEEE Symposium on Secu- rity and Privacy, SP, pages 178–...

  15. [23]

    Private Information Retrieval

    Benny Chor, Oded Goldreich, Eyal Kushilevitz, and Madhu Sudan. Private Information Retrieval. In Pro- ceedings of IEEE 36th Annual Foundations of Com- puter Science, pages 41–50, 1995

  16. [24]

    Top Threats to Cloud Computing Plus: Industry Insights

    Cloud Security Alliance. Top Threats to Cloud Computing Plus: Industry Insights. https: //cloudsecurityalliance.org/download/top- threats-cloud-computing-plus-industry- insights. Last accessed: August 7, 2019

  17. [25]

    Software Guard Extensions Pro- gramming Reference, Ref

    Intel Corp. Software Guard Extensions Pro- gramming Reference, Ref. 329298-002US. https://software.intel.com/sites/default/ files/managed/48/88/329298-002.pdf, 2014

  18. [26]

    Riposte: An Anonymous Messaging System Handling Millions of Users

    Henry Corrigan-Gibbs, Dan Boneh, and David Maz- ières. Riposte: An Anonymous Messaging System Handling Millions of Users. In 2015 IEEE Symposium on Security and Privacy, pages 321–338, 2015

  19. [27]

    Obladi: Oblivious Serializable Transactions in the Cloud

    Natacha Crooks, Matthew Burke, Ethan Cecchetti, Sitar Harel, Rachit Agarwal, and Lorenzo Alvisi. Obladi: Oblivious Serializable Transactions in the Cloud. In 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI) , pages 727–743, 2018

  20. [28]

    https://gitlab.com/cryptsetup/ cryptsetup

    cryptsetup. https://gitlab.com/cryptsetup/ cryptsetup. Last accessed: August 16, 2019

  21. [29]

    Pre- serving Access Pattern Privacy in SGX-Assisted En- crypted Search

    Shujie Cui, Sana Belguith, Ming Zhang, Muham- mad Rizwan Asghar, and Giovanni Russello. Pre- serving Access Pattern Privacy in SGX-Assisted En- crypted Search. In 2018 27th International Conference on Computer Communication and Networks (ICCCN), pages 1–9. IEEE, 2018

  22. [30]

    Onion ORAM: A Constant Bandwidth Blowup Obliv- ious RAM

    Srinivas Devadas, Marten van Dijk, Christopher W Fletcher, Ling Ren, Elaine Shi, and Daniel Wichs. Onion ORAM: A Constant Bandwidth Blowup Obliv- ious RAM. In Theory of Cryptography Conference, pages 145–174. Springer, 2016. 13

  23. [31]

    https: //www.kernel.org/doc/Documentation/device- mapper

    Linux Kernel device mapper framework. https: //www.kernel.org/doc/Documentation/device- mapper. Last accessed: August 7, 2019

  24. [32]

    Tor: The Second-Generation Onion Router

    Roger Dingledine, Nick Mathewson, and Paul Syver- son. Tor: The Second-Generation Onion Router. Technical report, Naval Research Lab Washington DC, 2004

  25. [33]

    https://gitlab.com/cryptsetup/ cryptsetup/wikis/DMCrypt

    DMCrypt. https://gitlab.com/cryptsetup/ cryptsetup/wikis/DMCrypt. Last accessed: August 16, 2019

  26. [34]

    https://gitlab.com/cryptsetup/ cryptsetup/wikis/DMIntegrity

    DMIntegrity. https://gitlab.com/cryptsetup/ cryptsetup/wikis/DMIntegrity. Last accessed: August 16, 2019

  27. [35]

    https://gitlab.com/cryptsetup/ cryptsetup/wikis/DMVerity

    DMVerity. https://gitlab.com/cryptsetup/ cryptsetup/wikis/DMVerity. Last accessed: Au- gust 16, 2019

  28. [36]

    Enterprise Container Platform for High- Velocity Innovation

    Docker. Enterprise Container Platform for High- Velocity Innovation. https://www.docker.com/. Last accessed: August 16, 2019

  29. [37]

    Insider Attacks in Cloud Computing

    Adrian J Duncan, Sadie Creese, and Michael Gold- smith. Insider Attacks in Cloud Computing. In 2012 IEEE 11th International Conference on Trust, Security and Privacy in Computing and Communications, pages 857–862, 2012

  30. [38]

    Jan-Erik Ekberg, Kari Kostiainen, and N. Asokan. Trusted execution environments on mobile devices. In 2013 ACM SIGSAC Conference on Computer and Com- munications Security, CCS, pages 1497–1498, 2013

  31. [39]

    ObliDB: Oblivi- ous Query Processing Using Hardware Enclaves.arXiv preprint arXiv:1710.00458, 2017

    Saba Eskandarian and Matei Zaharia. ObliDB: Oblivi- ous Query Processing Using Hardware Enclaves.arXiv preprint arXiv:1710.00458, 2017

  32. [40]

    Software pro- tection and simulation on oblivious rams

    Oded Goldreich and Rafail Ostrovsky. Software pro- tection and simulation on oblivious rams. J. ACM, 43(3):431–473, 1996

  33. [41]

    Probabilistic En- cryption

    Shafi Goldwasser and Silvio Micali. Probabilistic En- cryption. Journal of computer and system sciences , 28(2):270–299, 1984

  34. [42]

    Cache Attacks on Intel SGX

    Johannes Götzfried, Moritz Eckert, Sebastian Schinzel, and Tilo Müller. Cache Attacks on Intel SGX. In Pro- ceedings of the 10th European Workshop on Systems Security, EUROSEC, pages 2:1–2:6, 2017

  35. [43]

    https://github.com/oscarlab/graphene

    Graphene Library OS with Intel Registered SGX Sup- port. https://github.com/oscarlab/graphene. Last accessed: August 7, 2019

  36. [44]

    Attack Surfaces: A Taxonomy for Attacks on Cloud Services

    Nils Gruschka and Meiko Jensen. Attack Surfaces: A Taxonomy for Attacks on Cloud Services. In 2010 IEEE 3rd International Conference on Cloud Comput- ing, pages 276–279, 2010

  37. [45]

    What Bugs Live in the Cloud? A Study of 3000+ Issues in Cloud Systems

    Haryadi S Gunawi, Mingzhe Hao, Tanakorn Leesa- tapornwongsa, Tiratat Patana-anake, Thanh Do, Jef- fry Adityatama, Kurnia J Eliazar, Agung Laksono, Jef- frey F Lukman, Vincentius Martin, et al. What Bugs Live in the Cloud? A Study of 3000+ Issues in Cloud Systems. In Proceeding...

  38. [46]

    How Much Anonymity Does Network Latency Leak? ACM Transactions on Information and System Security (TISSEC), 13(2):13, 2010

    Nicholas Hopper, Eugene Y Vasserman, and Eric Chan- Tin. How Much Anonymity Does Network Latency Leak? ACM Transactions on Information and System Security (TISSEC), 13(2):13, 2010

  39. [47]

    Ryoan: A Distributed Sand- box for Untrusted Computation on Secret Data

    Tyler Hunt, Zhiting Zhu, Yuanzhong Xu, Simon Pe- ter, and Emmett Witchel. Ryoan: A Distributed Sand- box for Untrusted Computation on Secret Data. ACM Transactions on Computer Systems (TOCS), 35(4):13, 2018

  40. [48]

    IBM Cloud

    IBM. IBM Cloud. https://www.ibm.com/cloud. Last accessed: August 7, 2019

  41. [49]

    http://download.tensorflow.org/ example_images/flower_photos.tgz

    imagenet. http://download.tensorflow.org/ example_images/flower_photos.tgz. Last ac- cessed: August 7, 2019

  42. [50]

    Intel Software Guard Extensions

    Intel. Intel Software Guard Extensions. https: //software.intel.com/en-us/sgx. Last accessed: August 7, 2019

  43. [51]

    Intel(R) Software Guard Extensions for Linux* OS

    Intel. Intel(R) Software Guard Extensions for Linux* OS. https://github.com/intel/linux-sgx. Last accessed: August 16, 2019

  44. [52]

    Resources and Response to Side Channel L1TF

    Intel. Resources and Response to Side Channel L1TF. https://www.intel.com/content/www/us/en/ architecture-and-technology/l1tf.html. Last accessed: August 14, 2019

  45. [53]

    https://iperf.fr

    IPerf3. https://iperf.fr. Last accessed: August 7, 2019

  46. [54]

    Keynote: Scaling Towards Confi- dential Computing

    Simon Johnson. Keynote: Scaling Towards Confi- dential Computing. https://systex.ibr.cs.tu- bs.de/systex19/slides/systex19-keynote- simon.pdf

  47. [55]

    A Trust-Based Consumer Decision-Making Model in Electronic Commerce: The Role of Trust, Perceived Risk, and Their Antecedents.Decision support systems, 44(2):544–564, 2008

    Dan J Kim, Donald L Ferrin, and H Raghav Rao. A Trust-Based Consumer Decision-Making Model in Electronic Commerce: The Role of Trust, Perceived Risk, and Their Antecedents.Decision support systems, 44(2):544–564, 2008. 14

  48. [56]

    The art of computer program- ming, , Volume III, 2nd Edition

    Donald Ervin Knuth. The art of computer program- ming, , Volume III, 2nd Edition. Addison-Wesley, 1998

  49. [57]

    The CIFAR-10 dataset

    Alex Krizhevsky, Vinod Nair, and Geoffrey Hinton. The CIFAR-10 dataset. https://www.cs.toronto. edu/~kriz/cifar.html. Last accessed: August 16, 2019

  50. [58]

    Hin- ton

    Alex Krizhevsky, Ilya Sutskever, and Geoffrey E. Hin- ton. ImageNet Classification with Deep Convolutional Neural Networks. Commun. ACM, 60(6):84–90, 2017

  51. [59]

    To- wards Efficient Traffic-Analysis Resistant Anonymity Networks

    Stevens Le Blond, David Choffnes, Wenxuan Zhou, Peter Druschel, Hitesh Ballani, and Paul Francis. To- wards Efficient Traffic-Analysis Resistant Anonymity Networks. ACM SIGCOMM Computer Communica- tion Review, 43(4):303–314, 2013

  52. [60]

    Keystone: A Framework for Architecting TEEs

    Dayeol Lee, David Kohlbrenner, Shweta Shinde, Dawn Song, and Krste Asanovi´c. Keystone: A Framework for Architecting TEEs. arXiv preprint arXiv:1907.10119, 2019

  53. [61]

    Hacking in Darkness: Return-oriented Programming against Se- cure Enclaves

    Jae-Hyuk Lee, Jin Soo Jang, Yeongjin Jang, Nohyun Kwak, Yeseul Choi, Changho Choi, Taesoo Kim, Mar- cus Peinado, and Brent ByungHoon Kang. Hacking in Darkness: Return-oriented Programming against Se- cure Enclaves. In 26th USENIX Security Symposium, USENIX Security, pages 523–...

  54. [62]

    H-ORAM: A Cacheable ORAM Interface for Efficient I/O Accesses

    Liang Liu, Rujia Wang, Youtao Zhang, and Jun Yang. H-ORAM: A Cacheable ORAM Interface for Efficient I/O Accesses. In Proceedings of the 56th Annual De- sign Automation Conference 2019, page 33, 2019

  55. [63]

    https://lkml

    WireGuard: Secure Network Tunnel. https://lkml. org/lkml/2019/3/22/95. Last accessed: August 16, 2019

  56. [64]

    spectre-attack-sgx

    LSDS. spectre-attack-sgx. https://github.com/ lsds/spectre-attack-sgx. Last accessed: August 7, 2019

  57. [65]

    https://github.com/halayli/lthread

    lthread. https://github.com/halayli/lthread. Last accessed: August 16, 2019

  58. [66]

    5 Devious Instances of Insider Threat in the Cloud

    McAfee. 5 Devious Instances of Insider Threat in the Cloud. https://www.skyhighnetworks.com/ cloud-security-blog/5-devious-instances- insider-threat-cloud/. Last accessed: August 7, 2019

  59. [67]

    What is Memcached? https:// memcached.org/

    Memcached. What is Memcached? https:// memcached.org/. Last accessed: August 16, 2019

  60. [68]

    Azure Confidential Comput- ing

    Microsoft. Azure Confidential Comput- ing. https://azure.microsoft.com/en- gb/blog/azure-confidential-computing. Last accessed: August 7, 2019

  61. [69]

    Open Enclave SDK

    Microsoft. Open Enclave SDK. https:// openenclave.io/sdk/. Last accessed: August 16, 2019

  62. [70]

    Oblix: An Efficient Oblivious Search Index

    Pratyush Mishra, Rishabh Poddar, Jerry Chen, Alessan- dro Chiesa, and Raluca Ada Popa. Oblix: An Efficient Oblivious Search Index. In 2018 IEEE Symposium on Security and Privacy (SP), pages 279–296, 2018

  63. [71]

    CacheZoom: How SGX Amplifies the Power of Cache Attacks

    Ahmad Moghimi, Gorka Irazoqui, and Thomas Eisen- barth. CacheZoom: How SGX Amplifies the Power of Cache Attacks. In Cryptographic Hardware and Embedded Systems - CHES 2017 - 19th International Conference, pages 69–90. Springer, 2017

  64. [72]

    Low-Cost Traffic Analysis of Tor

    Steven J Murdoch and George Danezis. Low-Cost Traffic Analysis of Tor. In 2005 IEEE Symposium on Security and Privacy (S&P’), pages 183–195, 2005

  65. [73]

    https://www.musl-libc.orgs

    Musl. https://www.musl-libc.orgs. Last ac- cessed: August 7, 2019

  66. [74]

    What Is a Lift and Shift Cloud Migra- tion? https://cloud.netapp.com/blog/what-is- a-lift-and-shift-cloud-migration

    NetApp. What Is a Lift and Shift Cloud Migra- tion? https://cloud.netapp.com/blog/what-is- a-lift-and-shift-cloud-migration . Last ac- cessed: August 14, 2019

  67. [75]

    Varys: Protecting SGX Enclaves from Practical Side-Channel Attacks

    Oleksii Oleksenko, Bohdan Trach, Robert Krahn, Mark Silberstein, and Christof Fetzer. Varys: Protecting SGX Enclaves from Practical Side-Channel Attacks. In2018 USENIX Annual Technical Conference, USENIX ATC, pages 227–240, 2018

  68. [76]

    HealthGear: A Real-Time Wearable System for Monitoring and Analyzing Physiological Signals

    Nuria Oliver and Fernando Flores-Mangas. HealthGear: A Real-Time Wearable System for Monitoring and Analyzing Physiological Signals. In International Workshop on Wearable and Implantable Body Sensor Networks (BSN) , pages 4–pp. IEEE, 2006

  69. [77]

    Open Portable Trusted Execution Environ- ment

    OP-TEE. Open Portable Trusted Execution Environ- ment. https://www.op-tee.org/. Last accessed: August 7, 2019

  70. [78]

    Cache Attacks and Countermeasures: The Case of AES

    Dag Arne Osvik, Adi Shamir, and Eran Tromer. Cache Attacks and Countermeasures: The Case of AES. In Cryptographers’ Track at the RSA Conference, pages 1–20. Springer, 2006

  71. [79]

    https://github.com/ shwetasshinde24/Panoply

    Panoply Source Code. https://github.com/ shwetasshinde24/Panoply. Last accessed: August 7, 2019

  72. [80]

    CacheShuffle: A Family of Oblivious Shuffles

    Sarvar Patel, Giuseppe Persiano, and Kevin Yeo. CacheShuffle: A Family of Oblivious Shuffles. In 45th International Colloquium on Automata, Languages, and Programming, ICALP, pages 161:1–161:13, 2018. 15

  73. [81]

    Rethinking the Library OS From the Top Down

    Donald E Porter, Silas Boyd-Wickizer, Jon Howell, Reuben Olinsky, and Galen C Hunt. Rethinking the Library OS From the Top Down. In ACM SIGARCH Computer Architecture News, volume 39, pages 291– 304, 2011

  74. [82]

    The GNU C Library (glibc)

    GNU project. The GNU C Library (glibc). https:// www.gnu.org/software/libc/. Last accessed: Au- gust 7, 2019

  75. [83]

    LKL: The linux kernel library

    Octavian Purdila, Lucian Adrian Grijincu, and Nicolae Tapus. LKL: The linux kernel library. In9th RoEduNet IEEE International Conference, pages 328–333, 2010

  76. [84]

    Rac- coon: Closing Digital Side-Channels Through Obfus- cated Execution

    Ashay Rane, Calvin Lin, and Mohit Tiwari. Rac- coon: Closing Digital Side-Channels Through Obfus- cated Execution. In 24th USENIX Security Symposium (USENIX Security), pages 431–446, 2015

  77. [85]

    http://man7

    Read(2) Linux Programmer’s Manual. http://man7. org/linux/man-pages/man2/read.2.html. Last accessed: August 14, 2019

  78. [86]

    Trusted Execution Environment: What It Is, and What It Is Not

    Mohamed Sabt, Mohammed Achemlal, and Abdelmad- jid Bouabdallah. Trusted Execution Environment: What It Is, and What It Is Not. In 2015 IEEE Trust- com/BigDataSE/Ispa, pages 57–64, 2015

  79. [87]

    ZeroTrace: Oblivious Memory Primitives From Intel SGX

    Sajin Sasy, Sergey Gorbunov, and Christopher Fletcher. ZeroTrace: Oblivious Memory Primitives From Intel SGX. In Symposium on Network and Distributed Sys- tem Security (NDSS), 2018

  80. [88]

    ZombieLoad: Cross-Privilege-Boundary Data Sampling

    Michael Schwarz, Moritz Lipp, Daniel Moghimi, Jo Van Bulck, Julian Stecklina, Thomas Prescher, and Daniel Gruss. ZombieLoad: Cross-Privilege-Boundary Data Sampling. arXiv preprint arXiv:1905.05726 , 2019

  81. [89]

    Introducing MultiZone™ Secure IoT Stack - the first Secure IoT Stack for RISC-V

    HEX-Five Security. Introducing MultiZone™ Secure IoT Stack - the first Secure IoT Stack for RISC-V . https://hex-five.com/. Last accessed: August 7, 2019

  82. [90]

    Panoply: Low-TCB Linux Applications With SGX Enclaves

    Shweta Shinde, DL Tien, Shruti Tople, and Prateek Saxena. Panoply: Low-TCB Linux Applications With SGX Enclaves. In Proceedings of the Annual Network and Distributed System Security Symposium (NDSS), page 12, 2017

  83. [91]

    Eluding Carnivores: File Sharing With Strong Anonymity

    Emin Gün Sirer, Sharad Goel, Mark Robson, and Doˇgan Engin. Eluding Carnivores: File Sharing With Strong Anonymity. In Proceedings of the 11th Work- shop on ACM SIGOPS European Workshop, page 19, 2004

  84. [92]

    Fletcher, Ling Ren, Xiangyao Yu, and Srinivas Devadas

    Emil Stefanov, Marten van Dijk, Elaine Shi, Christo- pher W. Fletcher, Ling Ren, Xiangyao Yu, and Srinivas Devadas. Path ORAM: an extremely simple oblivious RAM protocol. In 2013 ACM SIGSAC Conference on Computer and Communications Security, CCS, pages 299–310, 2013

  85. [93]

    Recursive M-ORAM: A Matrix ORAM for Clients With Constrained Storage Space

    Karin Sumongkayothin, Steven Gordon, Atsuko Miyaji, Chunhua Su, and Komwut Wipusitwarakun. Recursive M-ORAM: A Matrix ORAM for Clients With Constrained Storage Space. In International Con- ference on Applications and Techniques in Information Security, pages 130–141. Springer, 2016

  86. [94]

    Splitting Interfaces: Making Trust Between Applications and Operating Systems Configurable

    Richard Ta-Min, Lionel Litty, and David Lie. Splitting Interfaces: Making Trust Between Applications and Operating Systems Configurable. In 7th Symposium on Operating Systems Design and Implementation (OSDI), pages 279–292, 2006

  87. [95]

    https://linux.die.net/man/8/ tc-htb

    tc-htb manpage. https://linux.die.net/man/8/ tc-htb. Last accessed: January 11, 2020

  88. [96]

    https://linux.die.net/man/8/ tc-prio

    tc-htb manpage. https://linux.die.net/man/8/ tc-prio. Last accessed: January 11, 2020

  89. [97]

    http://man7.org/linux/man-pages/ man8/tc.8.html

    tc manpage. http://man7.org/linux/man-pages/ man8/tc.8.html. Last accessed: January 11, 2020

  90. [98]

    Dropbox and Box leak files in security through obscurity nightmare

    Tech Republic. Dropbox and Box leak files in security through obscurity nightmare. . Last accessed: August 7, 2019

  91. [99]

    https://www.tensorflow.org/

    TensorFlow. https://www.tensorflow.org/. Last accessed: August 7, 2019

  92. [100]

    https://github.com/ tensorflow/benchmarks

    TensorFlow Benchmarks. https://github.com/ tensorflow/benchmarks. Last accessed: August 7, 2019

  93. [101]

    Porter, and Mona Vij

    Chia-Che Tsai, Donald E. Porter, and Mona Vij. Graphene-SGX: A Practical Library OS for Unmod- ified Applications on SGX. In Proceedings of the USENIX Annual Technical Conference (ATC), page 8, 2017

  94. [102]

    Stadium: A Distributed Metadata-Private Messaging System

    Nirvan Tyagi, Yossi Gilad, Derek Leung, Matei Za- haria, and Nickolai Zeldovich. Stadium: A Distributed Metadata-Private Messaging System. In Proceedings of the 26th Symposium on Operating Systems Princi- ples, pages 423–440, 2017

  95. [103]

    Princeton University. PARSEC. https://parsec.cs. princeton.edu/. Last accessed: August 7, 2019

  96. [104]

    Foreshadow: Extracting the Keys to the Intel SGX Kingdom With Transient Out-Of-Order Execu- tion

    Jo Van Bulck, Marina Minkin, Ofir Weisse, Daniel Genkin, Baris Kasikci, Frank Piessens, Mark Silber- stein, Thomas F Wenisch, Yuval Yarom, and Raoul Strackx. Foreshadow: Extracting the Keys to the Intel SGX Kingdom With Transient Out-Of-Order Execu- tion. In 27th USENIX Securit...

  97. [105]

    Garcia, and Frank Piessens

    Jo Van Bulck, David Oswald, Eduard Marin, Abdulla Aldoseri, Flavio D. Garcia, and Frank Piessens. A Tale of Two Worlds: Assessing the Vulnerability of Enclave Shielding Runtimes. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communica- tions Security, CCS, p...

  98. [106]

    Vuvuzela: Scalable Private Mes- saging Resistant to Traffic Analysis

    Jelle Van Den Hooff, David Lazar, Matei Zaharia, and Nickolai Zeldovich. Vuvuzela: Scalable Private Mes- saging Resistant to Traffic Analysis. In Proceedings of the 25th Symposium on Operating Systems Principles, pages 137–152. ACM, 2015

  99. [107]

    http://man7.org/linux/man- pages/man7/vdso.7.html

    vDSO manpage. http://man7.org/linux/man- pages/man7/vdso.7.html. Last accessed: August 7, 2019

  100. [108]

    Interface-Based Side Channel Attack Against Intel SGX

    Jinwen Wang, Yueqiang Cheng, Qi Li, and Yong Jiang. Interface-Based Side Channel Attack Against Intel SGX. arXiv preprint arXiv:1811.05378, 2018

  101. [109]

    Circuit ORAM: On Tightness of the Goldreich-Ostrovsky Lower Bound

    Xiao Wang, Hubert Chan, and Elaine Shi. Circuit ORAM: On Tightness of the Goldreich-Ostrovsky Lower Bound. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communica- tions Security, pages 850–861, 2015

  102. [110]

    AsyncShock: Exploiting Synchro- nisation Bugs in Intel SGX Enclaves

    Nico Weichbrodt, Anil Kurmus, Peter Pietzuch, and Rüdiger Kapitza. AsyncShock: Exploiting Synchro- nisation Bugs in Intel SGX Enclaves. In European Symposium on Research in Computer Security, pages 440–457. Springer, 2016

  103. [111]

    Pri- vatefs: A Parallel Oblivious File System

    Peter Williams, Radu Sion, and Alin Tomescu. Pri- vatefs: A Parallel Oblivious File System. In Proceed- ings of the 2012 ACM Conference on Computer and Communications Security, pages 977–988, 2012

  104. [112]

    https://www.wireguard.com/

    WireGuard. https://www.wireguard.com/. Last accessed: August 7, 2019

  105. [113]

    Dissent in Numbers: Mak- ing Strong Anonymity Scale

    David Isaac Wolinsky, Henry Corrigan-Gibbs, Bryan Ford, and Aaron Johnson. Dissent in Numbers: Mak- ing Strong Anonymity Scale. In Presented as Part of the 10th USENIX Symposium on Operating Systems Design and Implementation (OSDI), pages 179–182, 2012

  106. [114]

    Controlled-Channel Attacks: Deterministic Side Chan- nels for Untrusted Operating Systems

    Yuanzhong Xu, Weidong Cui, and Marcus Peinado. Controlled-Channel Attacks: Deterministic Side Chan- nels for Untrusted Operating Systems. In Security and Privacy (SP), 2015 IEEE Symposium On , pages 640–656, 2015

  107. [115]

    Security Models and Require- ments for Healthcare Application Clouds

    Rui Zhang and Ling Liu. Security Models and Require- ments for Healthcare Application Clouds. In 2010 IEEE 3rd International Conference on Cloud Comput- ing, pages 268–275, 2010. 17

Pith tools

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