pith. sign in

arxiv: 2501.04580 · v2 · submitted 2025-01-08 · 💻 cs.CR · cs.OS

Goldilocks Isolation: High Performance VMs with Edera

Marina Moore , Alex Zenla This is my paper

Pith reviewed 2026-05-23 05:44 UTC · model grok-4.3

classification 💻 cs.CR cs.OS
keywords hypervisorparavirtualizationcontainer runtimeKubernetesdriver isolationtype-1 hypervisorcloud securityvirtualization performance
0
0 comments X

The pith

Edera uses paravirtualization in a type-1 hypervisor to match Docker performance while adding full hypervisor isolation.

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

The paper introduces Edera as a type-1 hypervisor that applies paravirtualization to close the performance gap with operating-system virtualization. It demonstrates this through a Kubernetes-compatible container runtime that runs as a drop-in replacement and through isolation of hardware drivers for networking, storage, and GPUs. Performance measurements show CPU speeds 0.9 percent slower than Docker, system calls averaging 3 percent faster, and memory performance 0 to 7 percent faster, with a 648-millisecond increase in startup time. The central motivation is the large attack surface created when multiple tenants share a single kernel in container systems.

Core claim

Edera achieves hypervisor isolation with performance comparable to Docker by optimizing a type-1 hypervisor with paravirtualization, yielding 0.9 percent slower CPU, 3 percent faster system calls on average, and 0-7 percent faster memory while remaining compatible with the full Kubernetes ecosystem and supporting driver isolation use cases.

What carries the argument

Paravirtualization optimizations inside a type-1 hypervisor that reduce virtualization overhead for system calls, CPU, and memory while preserving separate address spaces and kernel instances.

If this is right

  • Kubernetes operators can replace the default runtime with Edera without changing application manifests or tooling.
  • Vulnerable device drivers can be moved into isolated VMs so that a driver bug cannot compromise the hypervisor or other tenants.
  • Cloud providers gain an option that combines container-like startup and throughput with kernel-level separation between tenants.

Where Pith is reading between the lines

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

  • The same paravirtualization techniques might be applied to other type-1 hypervisors to narrow the performance gap with containers.
  • Driver isolation could extend to other privileged components such as user-space networking stacks.
  • If startup latency remains the main cost, batching or pre-warming techniques could be tested to reduce the 648-millisecond overhead.

Load-bearing premise

The paravirtualization changes and type-1 design preserve full hypervisor isolation without adding new attack surfaces or causing regressions under real workloads.

What would settle it

Discovery of a container-escape attack that succeeds against Edera, or a benchmark showing more than a few percent slowdown in CPU, memory, or system-call throughput on production workloads.

Figures

Figures reproduced from arXiv: 2501.04580 by Alex Zenla, Marina Moore.

Figure 1
Figure 1. Figure 1: A summary comparison of different virtualization [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: An overview of how Edera isolates zones. [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: An overview of the services used by Edera. [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: An overview of the use of Edera for GPU isolation. GPU drivers are moved from the hypervisor into a zone so that any [PITH_FULL_IMAGE:figures/full_fig_p009_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: A comparison of the memory speed in MB/s using [PITH_FULL_IMAGE:figures/full_fig_p009_5.png] view at source ↗
Figure 7
Figure 7. Figure 7: A comparison of the operations per second of system [PITH_FULL_IMAGE:figures/full_fig_p010_7.png] view at source ↗
Figure 10
Figure 10. Figure 10: A comparison of runtime of nginx in milliseconds. [PITH_FULL_IMAGE:figures/full_fig_p010_10.png] view at source ↗
read the original abstract

Organizations run applications on cloud infrastructure shared between multiple users and organizations. Popular tooling for this shared infrastructure, including Docker and Kubernetes, supports such multi-tenancy through the use of operating system virtualization. With operating system virtualization (known as containerization), multiple applications share the same kernel, reducing the runtime overhead. However, this shared kernel presents a large attack surface and has led to a proliferation of container escape attacks in which a kernel exploit lets an attacker escape the isolation of operating system virtualization to access other applications or the operating system itself. To address this, some systems have proposed a return to hypervisor virtualization for stronger isolation between applications. However, no existing system has achieved both the isolation of hypervisor virtualization and the performance and usability of operating system virtualization. We present Edera, an optimized type 1 hypervisor that uses paravirtualization to improve the runtime of hypervisor virtualization. We illustrate Edera's usability and performance through two use cases. First, we create a container runtime compatible with Kubernetes that runs on the Edera hypervisor. This implementation can be used as a drop-in replacement for the Kubernetes runtime and is compatible with all the tooling in the Kubernetes ecosystem. Second, we use Edera to provide driver isolation for hardware drivers, including those for networking, storage, and GPUs. This use of isolation protects the hypervisor and other applications from driver vulnerabilities. We find that Edera has runtime comparable to Docker with .9% slower cpu speeds, an average of 3% faster system call performance, and memory performance 0-7% faster. It achieves this with a 648 millisecond increase in startup time from Docker's 177.4 milliseconds.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 0 minor

Summary. The paper presents Edera, an optimized type-1 hypervisor employing paravirtualization to deliver hypervisor-level isolation between tenants while achieving runtime performance comparable to OS-level containerization (Docker). It demonstrates usability through a Kubernetes-compatible container runtime (drop-in replacement) and a driver-isolation mechanism for networking/storage/GPU drivers. Performance is reported as 0.9% slower CPU, 3% faster average system-call performance, 0-7% faster memory performance, and a 648 ms increase in startup latency relative to Docker's 177.4 ms baseline.

Significance. If the performance numbers and isolation properties are substantiated, Edera would address a long-standing tension in cloud multi-tenancy by combining the attack-surface reduction of hypervisor virtualization with near-container performance and Kubernetes compatibility. The engineering focus on paravirtualization optimizations and the two concrete use cases (Kubernetes runtime and driver isolation) are practical contributions; however, the absence of any security evaluation or detailed performance methodology currently prevents the central claim from being assessed.

major comments (2)
  1. [Abstract] Abstract: the performance deltas (0.9% CPU, 3% syscall, 0-7% memory) are stated without any description of experimental methodology, workloads, hardware configuration, baseline Docker setup, number of runs, or error bars. This directly undermines the central claim that Edera matches Docker performance while adding isolation.
  2. [Abstract] Abstract and use-case sections: the claim that Edera provides 'the isolation of hypervisor virtualization' (no shared kernel, resistance to container escapes) rests solely on the type-1 + paravirtualization design assertion. No security analysis, attack-surface enumeration, or empirical testing against escape vectors on the paravirtual interfaces is supplied, leaving the isolation half of the 'Goldilocks' claim without evidence.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for their review and constructive feedback on the manuscript. We address each major comment point-by-point below, providing clarifications on the performance claims and isolation properties. We are prepared to revise the abstract for greater clarity on methodology while maintaining that the isolation claims are substantiated by the architectural design.

read point-by-point responses

  1. Referee: [Abstract] Abstract: the performance deltas (0.9% CPU, 3% syscall, 0-7% memory) are stated without any description of experimental methodology, workloads, hardware configuration, baseline Docker setup, number of runs, or error bars. This directly undermines the central claim that Edera matches Docker performance while adding isolation.

    Authors: We agree that the abstract's brevity omits key methodological details. The full Evaluation section describes the workloads (standard CPU, syscall, and memory benchmarks), hardware configuration, Docker baseline setup, number of runs, and error bars supporting the reported deltas. To improve accessibility, we will revise the abstract to include a concise reference to the evaluation methodology and direct readers to the detailed section. This change will better support the central performance claim. revision: yes

  2. Referee: [Abstract] Abstract and use-case sections: the claim that Edera provides 'the isolation of hypervisor virtualization' (no shared kernel, resistance to container escapes) rests solely on the type-1 + paravirtualization design assertion. No security analysis, attack-surface enumeration, or empirical testing against escape vectors on the paravirtual interfaces is supplied, leaving the isolation half of the 'Goldilocks' claim without evidence.

    Authors: The isolation guarantee follows directly from the type-1 hypervisor architecture with paravirtualization, which enforces separate kernels per tenant and eliminates the shared-kernel attack surface responsible for container escapes. The System Design section enumerates the paravirtual interfaces and their security properties. Empirical exploit testing is outside the paper's scope, which prioritizes performance and usability demonstrations; such testing would require a specific threat model not central to the contribution. The design-based argument is standard for hypervisor isolation claims and is sufficient here. revision: no

Circularity Check

0 steps flagged

No circularity: engineering systems paper with empirical benchmarks only

full rationale

The paper describes a type-1 hypervisor implementation and reports direct performance measurements against Docker (CPU, syscall, memory, startup times). No equations, fitted parameters, predictions, or derivation chains appear in the provided text. Claims rest on implementation details and benchmark results rather than any self-referential logic or self-citation load-bearing steps. This matches the expected non-finding for a pure systems paper.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 1 invented entities

The central claim rests on the existence and measured behavior of the Edera implementation; no free parameters, mathematical axioms, or external benchmarks are referenced in the abstract.

invented entities (1)
  • Edera hypervisor no independent evidence
    purpose: Optimized type-1 hypervisor using paravirtualization to achieve high-performance VMs with strong isolation
    The system is introduced as the core contribution of the paper.

pith-pipeline@v0.9.0 · 5830 in / 1263 out tokens · 19691 ms · 2026-05-23T05:44:32.859500+00:00 · methodology

discussion (0)

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

Reference graph

Works this paper leans on

57 extracted references · 57 canonical work pages

  1. [1]

    Fire- cracker: Lightweight virtualization for serverless applications,

    A. Agache, M. Brooker, A. Iordache, A. Liguori, R. Neugebauer, P. Piwonka, and D.-M. Popa, “Fire- cracker: Lightweight virtualization for serverless applications,” in 17th USENIX Symposium on Net- worked Systems Design and Implementation (NSDI 20) . Santa Clara, CA: USENIX Association, Feb. 2020, pp. 419–434. [Online]. Available: https://www.usenix.org/ c...

    work page 2020

  2. [2]

    Amazon ec2 g4 instances,

    Amazon, “Amazon ec2 g4 instances,” https: //aws.amazon.com/ec2/instance-types/g4/, 2024, accessed 2024-10-28

    work page 2024

  3. [3]

    Prometheus,

    P. Authors, “Prometheus,” https://prometheus.io/, 2024, accessed 2024-10-21

    work page 2024

  4. [4]

    Xen and the art of virtualization,

    P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer, I. Pratt, and A. Warfield, “Xen and the art of virtualization,” SIGOPS Oper . Syst. Rev., vol. 37, no. 5, p. 164–177, Oct. 2003. [Online]. Available: https://doi.org/10.1145/1165389.945462

    work page doi:10.1145/1165389.945462 2003

  5. [5]

    When extended para-virtualization (xpv) meets numa,

    B. Bui, D. Mvondo, B. Teabe, K. Jiokeng, L. Wapet, A. Tchana, G. Thomas, D. Hagimont, G. Muller, and N. DePalma, “When extended para-virtualization (xpv) meets numa,” in Proceedings of the F ourteenth EuroSys Conference 2019, 2019, pp. 1–15

    work page 2019

  6. [6]

    CVE- 2022-0185

    “CVE- 2022-0185.” Feb. 11 2022. [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2022-0185

    work page 2022

  7. [7]

    CVE- 2022-0492

    “CVE- 2022-0492.” Feb. 6 2022. [Online]. Available: https://access.redhat.com/security/cve/cve-2022-0492

    work page 2022

  8. [8]

    CVE- 2022-0811

    “CVE- 2022-0811.” Mar. 16 2022. [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2022-0811

    work page 2022

  9. [9]

    CVE- 2022-0847

    “CVE- 2022-0847.” Mar. 10 2022. [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2022-0847

    work page 2022

  10. [10]

    CVE- 2022-23648

    “CVE- 2022-23648.” Mar. 3 2022. [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2022-23648

    work page 2022

  11. [11]

    CVE- 2024-0132

    “CVE- 2024-0132.” Sep. 26 2022. [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2024-0132

    work page 2024

  12. [12]

    Container secu- rity best practices: Securing build to runtime (and back),

    D. Galea and N. Carpenter, “Container secu- rity best practices: Securing build to runtime (and back),” https://orca.security/resources/blog/ container-security-best-practices/, 2024, accessed 2024-10-15

    work page 2024

  13. [13]

    GPU memory exploitation for fun and profit,

    Y . Guo, Z. Zhang, and J. Yang, “GPU memory exploitation for fun and profit,” in33rd USENIX Security Symposium (USENIX Security 24) . Philadelphia, PA: USENIX Association, Aug. 2024, pp. 4033–4050. [Online]. Available: https://www.usenix.org/conference/ usenixsecurity24/presentation/guo-yanan

    work page 2024

  14. [14]

    Gvim: Gpu-accelerated virtual machines,

    V . Gupta, A. Gavrilovska, K. Schwan, H. Kharche, N. Tolia, V . Talwar, and P. Ranganathan, “Gvim: Gpu-accelerated virtual machines,” in Proceedings of the 3rd ACM Workshop on System-Level Virtualization for High Performance Computing , ser. HPCVirt ’09. New York, NY , USA: Association for Computing Machinery, 2009, p. 17–24. [Online]. Available: https://...

    work page doi:10.1145/1519138.1519141 2009

  15. [15]

    Pvm: Efficient shadow paging for deploying secure containers in cloud-native environment,

    H. Huang, J. Lai, J. Rao, H. Lu, W. Hou, H. Su, Q. Xu, J. Zhong, J. Zeng, X. Wang, Z. He, W. Han, J. Liu, T. Ma, and S. Wu, “Pvm: Efficient shadow paging for deploying secure containers in cloud-native environment,” in Proceedings of the 29th Symposium on Operating Systems Principles , ser. SOSP ’23. New York, NY , USA: Association for Computing Machinery...

    work page doi:10.1145/3600006.3613158 2023

  16. [16]

    vkernel: Enhancing container iso- lation via private code and data,

    H. Huang, H. Wang, J. Rao, S. Wu, H. Fan, C. Yu, H. Jin, K. Suo, and L. Pan, “vkernel: Enhancing container iso- lation via private code and data,” IEEE Transactions on Computers, vol. 73, no. 7, pp. 1711–1723, 2024

    work page 2024

  17. [17]

    Keckler, Christopher W

    I. Jang, A. Tang, T. Kim, S. Sethumadhavan, and J. Huh, “Heterogeneous isolated execution for commodity gpus,” in Proceedings of the Twenty-F ourth International Conference on Architectural Support for Programming Languages and Operating Systems , ser. ASPLOS ’19. New York, NY , USA: Association for Computing Machinery, 2019, p. 455–468. [Online]. Availab...

    work page doi:10.1145/3297858.3304021 2019

  18. [18]

    kubelet,

    Kubernetes, “kubelet,” https://kubernetes.io/docs/ reference/command-line-tools-reference/kubelet/, 2024, accessed 2024-10-17

    work page 2024

  19. [19]

    Unikraft: fast, specialized unikernels the easy way,

    S. Kuenzer, V .-A. B˘adoiu, H. Lefeuvre, S. Santhanam, A. Jung, G. Gain, C. Soldani, C. Lupu, c. Teodorescu, C. R ˘aducanu, C. Banu, L. Mathy, R. Deaconescu, C. Raiciu, and F. Huici, “Unikraft: fast, specialized unikernels the easy way,” in Proceedings of the Sixteenth European Conference on Computer Systems , ser. EuroSys ’21. New York, NY , USA: Associa...

    work page doi:10.1145/3447786.3456248 2021

  20. [20]

    You can type, but you can’t hide: A stealthy gpu-based keylogger,

    E. Ladakis, L. Koromilas, G. Vasiliadis, M. Polychron- akis, and S. Ioannidis, “You can type, but you can’t hide: A stealthy gpu-based keylogger,”European Workshop on System Security (EuroSec), 2013

    work page 2013

  21. [21]

    Lock-in-Pop: Securing privileged operating system kernels by keeping on the beaten path,

    Y . Li, B. Dolan-Gavitt, S. Weber, and J. Cappos, “Lock-in-Pop: Securing privileged operating system kernels by keeping on the beaten path,” in2017 USENIX Annual Technical Conference (USENIX ATC 17). Santa Clara, CA: USENIX Association, Jul. 2017, pp. 1–13. 13 [Online]. Available: https://www.usenix.org/conference/ atc17/technical-sessions/presentation/li-yiwen

    work page 2017

  22. [22]

    RunD: A lightweight secure container runtime for high-density deployment and high-concurrency startup in serverless computing,

    Z. Li, J. Cheng, Q. Chen, E. Guan, Z. Bian, Y . Tao, B. Zha, Q. Wang, W. Han, and M. Guo, “RunD: A lightweight secure container runtime for high-density deployment and high-concurrency startup in serverless computing,” in 2022 USENIX Annual Technical Conference (USENIX ATC 22) . Carlsbad, CA: USENIX Association, Jul. 2022, pp. 53–68. [Online]. Available: ...

    work page 2022

  23. [23]

    Cps: A cooperative para-virtualized scheduling framework for manycore machines,

    Y . Liu, T. Xu, Z. Mi, Z. Hua, B. Zang, and H. Chen, “Cps: A cooperative para-virtualized scheduling framework for manycore machines,” in Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, V olume 4, ser. ASPLOS ’23. New York, NY , USA: Association for Computing Machinery, 2024, p...

    work page doi:10.1145/3623278 2024

  24. [24]

    Unikernels: library operating systems for the cloud,

    A. Madhavapeddy, R. Mortier, C. Rotsos, D. Scott, B. Singh, T. Gazagnaire, S. Smith, S. Hand, and J. Crowcroft, “Unikernels: library operating systems for the cloud,” in ASPLOS ’13 . New York, NY , USA: Association for Computing Machinery, 2013, p. 461–472. [Online]. Available: https://doi.org/10.1145/ 2451116.2451167

    work page arXiv 2013

  25. [25]

    Metalvisor: Introducing the first typezero hypervisor for next-gen security & performance,

    Mainsail, “Metalvisor: Introducing the first typezero hypervisor for next-gen security & performance,” https://www.mainsailindustries.com/metalvisor, 2024, accessed 2024-10-16

    work page 2024

  26. [26]

    Constellation: Always encrypted ku- bernetes,

    C. maintainers, “Constellation: Always encrypted ku- bernetes,” https://github.com/edgelesssys/constellation, 2024, accessed 2024-10-16

    work page 2024

  27. [27]

    The container security platform,

    g. maintainers, “The container security platform,” https: //gvisor.dev/, 2024, accessed 2024-10-28

    work page 2024

  28. [28]

    Infranetes,

    I. maintainers, “Infranetes,” https://github.com/apporbit/ infranetes, 2016, accessed 2024-10-28

    work page 2016

  29. [29]

    The speed of containers, the security of vms,

    K. maintainers, “The speed of containers, the security of vms,” https://katacontainers.io/, 2024, accessed 2024- 10-28

    work page 2024

  30. [30]

    Container runtime interface (cri),

    ——, “Container runtime interface (cri),” https:// kubernetes.io/docs/concepts/architecture/cri/, 2024, ac- cessed 2024-10-28

    work page 2024

  31. [31]

    Kubernetes,

    ——, “Kubernetes,” https://kubernetes.io/, 2024, ac- cessed 2024-10-28

    work page 2024

  32. [32]

    capabilities(7) - linux manual page,

    L. maintainers, “capabilities(7) - linux manual page,” https://man7.org/linux/man-pages/man7/capabilities.7. html, 2024, accessed 2024-10-23

    work page 2024

  33. [33]

    cgroups(7) - linux manual page,

    ——, “cgroups(7) - linux manual page,” https://man7. org/linux/man-pages/man7/cgroups.7.html, 2024, ac- cessed 2024-10-23

    work page 2024

  34. [34]

    namespaces(7) - linux manual page,

    ——, “namespaces(7) - linux manual page,” https: //man7.org/linux/man-pages/man7/namespaces.7.html, 2024, accessed 2024-10-23

    work page 2024

  35. [35]

    seccomp(2) - linux manual page,

    ——, “seccomp(2) - linux manual page,” https://man7. org/linux/man-pages/man2/seccomp.2.html, 2024, ac- cessed 2024-10-23

    work page 2024

  36. [36]

    What’s lxc,

    ——, “What’s lxc,” https://linuxcontainers.org/lxc/ introduction/, 2024, accessed 2024-10-16

    work page 2024

  37. [37]

    A programming framework for build- ing type-safe, modular systems,

    M. maintainers, “A programming framework for build- ing type-safe, modular systems,” https://mirage.io/, 2024, accessed 2024-10-28

    work page 2024

  38. [38]

    Running rkt with kvm stage1,

    r. maintainers, “Running rkt with kvm stage1,” https://github.com/rkt/rkt/blob/master/Documentation/ running-kvm-stage1.md, 2019, accessed 2024-10-28

    work page 2019

  39. [39]

    Runx: next generation secured containers,

    R. maintainers, “Runx: next generation secured containers,” https://xcp-ng.org/blog/2021/09/14/ runx-next-generation-secured-containers/, 2021, accessed 2024-10-28

    work page 2021

  40. [40]

    Selinux userspace,

    S. maintainers, “Selinux userspace,” https://github.com/ SELinuxProject/selinux, 2024, accessed 2024-10-16

    work page 2024

  41. [41]

    virtlet,

    v. maintainers, “virtlet,” https://github.com/Mirantis/ virtlet, 2019, accessed 2024-10-28

    work page 2019

  42. [42]

    Xen pv channels,

    X. maintainers, “Xen pv channels,” https: //xenbits.xenproject.org/docs/unstable/man/ xen-pv-channel.7.html, 2024, accessed 2024-10- 21

    work page 2024

  43. [43]

    My vm is lighter (and safer) than your container,

    F. Manco, C. Lupu, F. Schmidt, J. Mendes, S. Kuenzer, S. Sati, K. Yasukata, C. Raiciu, and F. Huici, “My vm is lighter (and safer) than your container,” inProceedings of the 26th Symposium on Operating Systems Principles , ser. SOSP ’17. New York, NY , USA: Association for Computing Machinery, 2017, p. 218–233. [Online]. Available: https://doi.org/10.1145...

    work page doi:10.1145/3132747.3132763 2017

  44. [44]

    X86-64 xenlinux: Architecture, implementation, and optimiza- tions,

    J. Nakajima, A. Mallick, I. Pratt, and K. Fraser, “X86-64 xenlinux: Architecture, implementation, and optimiza- tions,” in 2006 Linux Symposium, 2006

    work page 2006

  45. [45]

    Security bulletins,

    NVIDIA, “Security bulletins,” https://www.nvidia.com/ en-us/product-security/, 2024, accessed 2024-10-21. 14

    work page 2024

  46. [46]

    Unlock next level performance with vir- tual gpus,

    NVIDIA, “Unlock next level performance with vir- tual gpus,” https://www.nvidia.com/en-us/data-center/ virtual-solutions/, 2024, accessed 2024-10-17

    work page 2024

  47. [47]

    A binary-compatible unikernel,

    P. Olivier, D. Chiba, S. Lankes, C. Min, and B. Ravin- dran, “A binary-compatible unikernel,” inProceedings of the 15th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments , ser. VEE 2019. New York, NY , USA: Association for Computing Machinery, 2019, p. 59–73. [Online]. Available: https://doi.org/10.1145/3313808.3313817

    work page doi:10.1145/3313808.3313817 2019

  48. [48]

    Oxide cloud computer,

    Oxide, “Oxide cloud computer,” https://oxide.computer/, 2024, accessed 2024-10-16

    work page 2024

  49. [49]

    Safe and practical gpu computation in trustzone,

    H. Park and F. X. Lin, “Safe and practical gpu computation in trustzone,” in Proceedings of the Eighteenth European Conference on Computer Systems , ser. EuroSys ’23. New York, NY , USA: Association for Computing Machinery, 2023, p. 505–520. [Online]. Available: https://doi.org/10.1145/3552326.3567483

    work page doi:10.1145/3552326.3567483 2023

  50. [50]

    Apiary: Easy-to-Use desktop application fault containment on com- modity operating systems,

    S. Potter and J. Nieh, “Apiary: Easy-to-Use desktop application fault containment on com- modity operating systems,” in 2010 USENIX Annual Technical Conference (USENIX ATC 10) . USENIX Association, Jun. 2010. [Online]. Avail- able: https://www.usenix.org/conference/usenix-atc-10/ apiary-easy-use-desktop-application-fault-containment-commodity-operating

    work page 2010

  51. [51]

    Solaris zones: Operating system support for consolidating commercial workloads,

    D. Price and A. Tucker, “Solaris zones: Operating system support for consolidating commercial workloads,” in 18th Large Installation System Administration Conference (LISA 04) . Atlanta, GA: USENIX Association, Nov. 2004. [Online]. Available: https://www.usenix.org/conference/lisa-04/ solaris-zones-operating-system-support-consolidating-commercial-workloads

    work page 2004

  52. [52]

    Xenoservers: accountable execution of untrusted pro- grams,

    D. Reed, I. Pratt, P. Menage, S. Early, and N. Stratford, “Xenoservers: accountable execution of untrusted pro- grams,” in Proceedings of the Seventh Workshop on Hot Topics in Operating Systems, 1999, pp. 136–141

    work page 1999

  53. [53]

    GPUvm: Why not virtualizing GPUs at the hypervi- sor?

    Y . Suzuki, S. Kato, H. Yamada, and K. Kono, “GPUvm: Why not virtualizing GPUs at the hypervi- sor?” in 2014 USENIX Annual Technical Conference (USENIX ATC 14) . Philadelphia, PA: USENIX Association, Jun. 2014, pp. 109–120. [Online]. Available: https://www.usenix.org/conference/atc14/ technical-sessions/presentation/suzuki

    work page 2014

  54. [54]

    Gpu-assisted malware,

    G. Vasiliadis, M. Polychronakis, and S. Ioannidis, “Gpu-assisted malware,” Int. J. Inf. Secur . , vol. 14, no. 3, p. 289–297, Jun. 2015. [Online]. Available: https://doi.org/10.1007/s10207-014-0262-9

    work page doi:10.1007/s10207-014-0262-9 2015

  55. [55]

    Graviton: Trusted execution environments on GPUs,

    S. V olos, K. Vaswani, and R. Bruno, “Graviton: Trusted execution environments on GPUs,” in 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18) . Carlsbad, CA: USENIX Association, Oct. 2018, pp. 681–696. [Online]. Available: https://www.usenix.org/conference/osdi18/ presentation/volos

    work page 2018

  56. [56]

    Denali: Lightweight virtual machines for distributed and networked applications,

    A. Whitaker, M. Shaw, and S. D. Gribble, “Denali: Lightweight virtual machines for distributed and networked applications,” The University of Washington, Tech. Rep., 2001. [Online]. Avail- able: https://www.semanticscholar.org/paper/Denali% 3A-Lightweight-Virtual-Machines-for-and-Whitaker-Shaw/ 11928ecc96f52e153f6a3bf5143260f15f7c4dfd

    work page 2001

  57. [57]

    Efficient convex optimization on GPUs for embedded model predictive control,

    Z. Zhu, S. Kim, Y . Rozhanski, Y . Hu, E. Witchel, and M. Silberstein, “Understanding the security of discrete gpus,” in Proceedings of the General Purpose GPUs , ser. GPGPU-10. New York, NY , USA: Association for Computing Machinery, 2017, p. 1–11. [Online]. Available: https://doi.org/10.1145/3038228.3038233 15

    work page doi:10.1145/3038228.3038233 2017