Re: Why QEMU should move from C to Rust (clickbait alert ;))

[Alex Carter]

Hi everyone,

My name is Alex, I’m a student at the University of Michigan and I just completed an internship at IBM Research. There, I have been working on a project very related to this topic. I tested using Cloud Hypervisor’s Rust-based vhost-user virtiofs and block devices with QEMU. Bigger picture, I wanted to explore the implications of using Rust for vhost-user devices in QEMU. 

 

I agree with the points from the original post, namely:

·      C programming bugs are responsible for a large number of CVEs, and specifically CVEs coming from the implementations of virtual devices. 

·      As a programming language, Rust has matured to a point where it is worth considering it more seriously for production use. It has extensive libraries and community support. Many big players in the industry are already using Rust for production workloads.

 

Full Transparency: the Drawbacks:

It would be deceptive to only showcase Rust in an ideal light. 

·      The benchmarks I ran show a noticeable performance hit from switching to a RustVMM implementation of a virtiofsd device. 

·      While Rust has matured greatly, it still is missing a bit. One example of this that came up was that the rust compiler does not have Control Flow Integrity (CFI) features. While these are not as important as in “unsafe” languages such as C, the ability to express unsafe portions of code does allow for some types of memory bugs – although to a much lesser extent (an interesting case of this surfaced from Firecracker, and the handling of mmio [1]). So further protections such as Control Flow Integrity can still be desirable, even with rust code.

·      There have been years of optimization work put into the C implementations of these devices, and it’s hard to evaluate how optimized the relatively novel rust implementations are.

A piece of exciting news is that many of these drawbacks show a pathway for future improvement. Improvements to rust infrastructure are very realistic. Rust boils down to LLVM just like C, so porting over C’s CFI features should be feasible. If more development resources are put into the RustVMM project, there is no reason their implementations can’t be as optimized as the C versions, and this could be greatly aided by expertise coming from the QEMU communities familiarity with these topics.

 

I believe vhost-user devices are an excellent place to start since It lowers the entry barrier for developing in Rust. The device only has to interface with the C-based QEMU binary through a standardized protocol. It removes many worries of moving entirely away from C, since adding a set of Rust devices would simply be giving more options and room to explore. 

 

I am putting together the scripts I used for all of the tests at this repo:

https://github.com/Alex-Carter01/Qemu-Rust-Testing

I am working to standardize everything to make it easier to replicate. I would love any community involvement if people wanted to see how results differ based on the hardware setup, build configuration of the devices etc.

The repo also has links to a recording of my original presentation and the slides I was using if you would like to look at that format or see the discussion which came out of it.