We've identified the way forward: provide a fundamentally secure computing base by isolating applications using proven virtualization technologies. Each application in a container launches in its own minimal virtual machine environment, eliminating the shared kernel attack surface that makes traditional container escapes possible.
This design strategy was independently verified and implemented by Apple in the recent release of its Container Framework, enabling developers to deploy applications in VM-secured containers on their laptops. With a separate OS kernel and stronger boundaries separating applications from the rest of the host, escapes become more difficult. Their technical implementation—featuring vminitd as a minimal init system, optimized kernel configs, and dedicated networking for each container—validates that hypervisor-isolated containers can deliver both security and performance without compromise.
Apple's choice is significant: they could have built a traditional container runtime with namespace isolation, but instead chose the hypervisor-based approach because they understand that security matters, even in development. This creates an unprecedented opportunity for organizations to maintain hypervisor-level isolation across their entire development lifecycle—from local development with Apple's framework to production deployment with solutions like Edera.
We've developed our solution on top of the Xen hypervisor. This post explores three key technical reasons behind this choice: Xen's type-1 architecture, its paravirtualization capabilities, and its minimal trusted computing base.
Why Type-1 Hypervisors Like Xen Are Best for Container Security
Hypervisors come in two flavors: type-1 and type-2. They differ in architecture, security implications, and deployment strategies. Many benefits we leverage at Edera derive from using a type-1 hypervisor such as Xen.
A type-1 hypervisor boots natively as any other operating system would. It scans for hardware, installs interrupt handlers, leverages a serial console, configures memory, and establishes CPU contexts for scheduling. Fundamentally, it retains control over the hardware in the platform, much as any native operating system kernel would. As its purpose is simply to launch and support guest domains, it doesn't need the breadth of device support, flexibility, or functionality typically found in a general-purpose operating system like Linux or BSD.
Typical Xen deployments rely on a control domain called dom0 to serve the control software used to manage guests and as a backend for device drivers. Dom0 is itself a guest and hosts a generic operating system such as Linux or FreeBSD. For many use cases, however, Xen supports deployments with minimal support software in dom0, or can boot entirely without this domain, further reducing its footprint and dependencies. This flexibility is impossible with a type-2 hypervisor.
Given the reduced feature set and requirements, a smaller, independent code base such as Xen's provides significant benefits, including simpler logic and constructs that ease development and debugging.
In contrast, a type-2 (or “hosted”) hypervisor is implemented as an extension to an existing operating system kernel. KVM, for example, is provided as a module to the Linux kernel. As an extension, it would not own any of the hardware on the platform, relying instead on the soundness of the underlying kernel to provide protections.
Furthermore, an extension's implementation tightly integrates with its host kernel, relying on the host's functionality to supplement its own capabilities (such as VCPU scheduling) and reusing the constructs of the underlying kernel (in Linux, using mm_struct for guest address spaces). This impacts development, debugging, and deployment, as developers must understand the much larger code base. A type-1 hypervisor implements an interface at a hypercall layer (much like system calls) supporting more independent development.
There's also a necessary dependency between the device model process on the host operating system and its associated guest. In a type-2 hypervisor, since the hypervisor doesn't own the hardware or resources assigned to a guest, the device model process must instantiate a guest with its own memory and CPU resources. This contrasts with a type-1 design, where memory and CPU time are allocated and managed from within the hypervisor itself, providing cleaner separation of resource control.
The type-1 design in Xen gives us flexibility and improved security through better separation: device models become optional (as we see below), resources remain under the control of the smaller hypervisor, and cleaner interfaces define the interaction layers between components on the system.
Return of Paravirtualization To Enable Secure Cloud Deployments
Xen as an open-source project is uniquely positioned to run guests fully or partially paravirtualized, without heavy device emulation support.
Paravirtualization configures guests to avoid depending on hardware virtualization support, such as Intel's VT-x or AMD-V. Guest kernels are modified at the source level to avoid issuing privileged CPU instructions that would affect platform state, such as IO operations to devices. Instead, they invoke hypercalls to cooperatively invoke services of the underlying hypervisor, much like an application issues system calls to interact with the operating system. Paravirtual device drivers implement storage, network, and other device interfaces. Xen defines its own split-driver model, but also supports the virtIO standard.
Paravirtualization improves performance by avoiding emulation and reducing boot times, while supporting execution on CPUs with little or no support for secure hardware virtualization. This design existed over two decades ago, prior to the wealth of support found in today's CPUs.
Here's why paravirtualization matters for modern deployments: Most production workloads run in virtual machine environments within data centers that typically don't support nested virtualization. A virtual CPU doesn't expose VT-x or AMD-V, limiting the ability to run a hypervisor within an instance. By leveraging Xen's paravirtualization features, we can deploy Edera within these virtual instances, isolating container workloads into guests even when running on cloud provider infrastructure like AWS EC2 instances.
Since emulation of devices isn't needed, a paravirtual guest also doesn't require a device model. This means we don't need an emulator such as QEMU to support the guest context, which typically runs as a user space process in the control domain (or with KVM in the host environment). Device models such as QEMU are typically large monolithic code bases that implement numerous device types, and history has shown they're not without their own security challenges. QEMU bugs can crash the emulator, cause information leakage, or consume excessive resources on the host—many of which impact the behavior of the associated guest.
In environments where we have direct access to CPU virtualization support, Xen provides a guest model called PVH (PV with Hardware). In a PVH guest, the kernel remains fully paravirtualized and doesn't need emulation, yet VT-x or AMD-V accelerates page tables and system calls for simplification and performance. This benefits customer deployments with on-premises installations or in "bare metal" instances. We retain the same benefits of PV deployments while accelerating based on available silicon support for virtualization. PVH is the preferred guest model in Xen and is increasing in adoption.
How a Minimal Trusted Computing Base Makes Xen Ideal for Secure Containers
As mentioned earlier, the nature of a type-2 hypervisor requires integration with a host kernel, inheriting the complexity, challenges, and vulnerabilities that come with it. The Linux community is huge, with new changes going into the code base daily, the majority of which are unrelated to being a hypervisor.
The code base of a type-1 hypervisor can be small, and without a device model supporting guests, the universe of code supporting a workload becomes significantly reduced. We go further in Edera and retain a minimal boot environment in our guests—sufficient to support the application in a container.
As an independent piece of software, a type-1 hypervisor can focus on additions that contribute to its core functionality: virtualization. Everything else can be handled by the control domain, or even the guest. This model more closely aligns with microkernels, where only as much exists in the kernel as is necessary.
This brings significant benefits: arguably easier development and debugging, statistically fewer bugs, fewer vulnerabilities, and can even be practical to formally verify (cf. seL4 and NOVA).
To put this in perspective, the attack surface comparison is stark:
This isn't just about lines of code—it's about reducing the number of potential vulnerabilities in your security-critical path. At Edera, we have a Xen tooling stack written in Rust (comparable to the xl toolset written in C) and plans to provide an alternative to xenstored, further reducing our trusted computing base.
Proven in safety-critical systems
Xen is increasingly used in safety-critical contexts: automotive and flight systems, and is currently undergoing MISRA-C certification necessary for deployment in many of these environments.
Here, the maturity and size of a code base makes Xen attractive. Guidelines like MISRA-C impact the actual implementation of code bases, specifying particulars of the implementation. Bringing a system with many millions of lines of code into conformance is a massive undertaking, making a smaller code base more practical. This was a specific design goal of another hypervisor: ACRN, composed of 30k lines of implementation.
While we aren't currently targeting safety-critical environments, the fact that compelling use cases are adopting Xen demonstrates this software is stable and mature—in other words, a strong virtualization choice for our customers. Major cloud providers like AWS have built their infrastructure on Xen, proving its scalability and reliability in production environments.
Organizations can now maintain consistent security models from development through deployment—developers use Apple's Containerization Framework locally, then deploy the same OCI-compliant images to production with Edera.
This isn't just an incremental security improvement—it's a paradigm shift that lets security-conscious organizations build container workflows that never rely on the shared kernel model that can be escaped. Xen's type-1 architecture, paravirtualization capabilities, and minimal trusted computing base make it the ideal foundation for this security-first approach to container deployment.
