The Xen hypervisor project has a snarky April Fool’s blog post up in which they announce Xen Hypervisor to be Rewritten from C to Rust and Javascript, and perhaps PHP.
As a proponent of safe languages, I’ll use this as an opportunity to consider what it would be like to have a hypervisor written in a safe language (and yes, I think Rust could do most of it).
The Xen project has had many security flaws reported over the years. A recent paper did a survey:
Deconstructing Xen, by Lei Shi, Yuming Wu, Yubin Xia, Nathan Dautenhahn, Haibo Chen, Binyu Zang, Haibing Guan, and Jinming Li, NDSS 2017.
They start out with this:
Unfortunately, one of the most widely-used hypervisors, Xen, is highly susceptible to attack because it employs a monolithic design (a single point of failure) and comprises a complex set of growing functionality including VM management, scheduling, instruction emulation, IPC (event channels), and memory management. As Xen’s functionality has increased so too has its code base, rising from 45K lines-of-code (LoC) in v2.0 to 270K LoC in v4.0. Such a large code base inevitably leads to a large number of bugs that become security vulnerabilities. Attackers can easily exploit a known hypervisor vulnerability to “jail break” from a guest VM to the hypervisor to gain full control of the system. For example, a privilege escalation caused by non-canonical address handling (in a hypercall) can lead to an attacker gaining control of Xen, undermining all security in multi-tenant cloud environments.
Xen’s problems are safety problems
According to the paper’s analysis of Xen vulnerabilities, fully 45% stem from memory corruption, which is a kind of flaw that is particular to unsafe languages like C, and which is prevented in safe languages like Rust. Memory corruption is the most common cause of vulnerabilities in Xen (Table II).
The paper also tallies up the “results” of the different attacks (Table III). The most serious result is privilege escalation to host, i.e., the attacker is able to take over the machine hosting the virtual machines, completely compromising the hypervisor.
And how many of these very serious kinds of attack stem from memory corruption? The answer is not presented in the paper. However, I contacted the first author, Lei Shi, who kindly supplied the raw data. It turns out that memory corruption is behind 18 out of the 22 “privilege escalation to host” results, or 82%.
So I’ll repeat myself: when it comes to security, the important bugs are memory corruption bugs in code written in unsafe languages.
And now for the snark
The snark in the Xen post is directed at safe language proponents who say, “Just rewrite it in a safe language, that will solve the problem.”
The thing is, no one is saying that. That’s a strawman argument.
It’s hard to rewrite 270,000 lines of code in a new language. It’s hard to write very low-level code in a safe language. It’s hard to replicate all of the low-level performance-enhancing hacks of C code in a safe language. Nobody denies that.
The argument is, first, stop digging when you are in a hole. By default you should start new projects in a safe language. By default you should try to write new libraries or significant new functionalities in safe languages.
And second, it’s worth considering rewriting pieces of your program in safe languages. Eventually everything gets rewritten.
And finally, safe languages are not the only technology you should use—again, no one is saying that they solve all security problems. For example, the “Deconstructing Xen” paper is mostly about non-language techniques for securing Xen.
Previously
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28.