Goldilocks Isolation: High Performance VMs with Edera

TL;DR

Edera proposes a paravirtualized type-1 microkernel hypervisor that runs each container in an isolated zone with its own guest kernel, eliminating the shared kernel inherent to OS virtualization. It achieves near-OS-virtualization performance while delivering strong isolation, including GPU driver zone isolation, and provides Kubernetes-compatible runtimes as a drop-in replacement. Empirical results show Edera generally outperforms gVisor and approaches Docker/Kata in CPU and memory metrics, with startup times higher but configurable via warm zones. The work demonstrates practical multi-tenant security improvements for cloud workloads and outlines future enhancements in driver support and hardware-assisted security.

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.

Figures (10)

• Figure 1: A summary comparison of different virtualization designs. Note that containers in this diagram use operating system virtualization, sharing a kernel across all applications.
• Figure 2: An overview of how Edera isolates zones.
• Figure 3: An overview of the services used by Edera.
• 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 misbehavior cannot effect the hypervisor or other zones.
• Figure 5: A comparison of the memory speed in MB/s using metrics from both sysbench and perf-bench. Higher is better.