So using Rust is a good start, but how else are we reducing our attack surface? The big one is by reducing the amount of code running in our hypervisor. In this post we’ll look at a few metrics for what “less code” actually means, so you can see for yourself how we achieve this.
First, some background. Edera is a Xen-based hypervisor that creates a hardened runtime that enables strong workload isolation. It achieves similar performance to running workloads on bare metal, while providing strong isolation that makes secure multi-tenancy possible. Edera runs workloads in a microVM-like environment we call zones.
Other popular microVM systems use KVM as their hypervisor, which runs as a module in the Linux kernel. KVM generally sits below a virtual machine monitor (VMM) like Firecracker or Cloud hypervisor. Confusingly people like to refer to VMMs as hypervisors as well.
The big reason our hypervisor has a smaller attack surface is the use of Xen instead of KVM. Xen and KVM are the part of the system that runs in hardware ring 0, the most trusted hardware ring. Guest operating systems run in ring 3, a less trusted hardware ring. So the first metrics we’ll look at evaluate the amount of code running in the privileged ring 0.
Source line of code comparison
Initially, we took a naive approach and used the open source sloc tool to measure the source lines of code in Linux (the base of KVM) and Xen. Linux has 18,313,464 sloc while Xen has 79,161 this gives us a 99.6% reduction in potentially hardware privileged code through the use of Xen. However, as we dove deeper into what SLOC means for these particular codebases, we knew there had to be a better way.
Pages in ring 0 comparison
In order to get a more accurate comparison, we’ll next look at the actual number of executable ring 0 pages. To determine this, we look at the size of all Xen and Linux components on disk, taking into account page size offsets. Looking at all the .text and .data pages, Xen has a 91% reduction in the number of ring 0 executable pages when compared to Linux. Interestingly when you include NVIDIA drivers this goes up to a 94% reduction.
This number accounts for page-alignment and data, unlike the above source lines of code number, making it more accurate to what you see on disk. But bugs usually come from the code complexity, so both are good to look at.
Attack Surface Above the Hypervisor
But what about what runs on top of the hypervisor? The numbers above only look at code running in ring 0. While ring 0 has special hardware privileges, a guest OS running in ring 3 can still have bugs that allow an attacker access to the hypervisor or perform arbitrary hypercalls. A hypervisor attack chain will likely include a kernel vulnerability that lets the attacker get to the hypervisor in the first place. So what’s running inside the guest OS also matters.
So by looking at the compiled lines of code in the hypervisor plus the drivers and the guest operating system, we include all of the code your application has to trust. We find that paravirtualized Xen reduces the total amount of trusted code by 66% compared to KVM.
Conclusion
So how much do we reduce the hypervisor attack surface? I don’t know, but all the metrics show that we do reduce it. While it’s not always possible to get a single number that illustrates the security posture of a piece of software, I hope this analysis helped you understand how we think about attack surface reduction, and building a minimal hypervisor to make the internet more secure.
