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

[Sergio Lopez <slp@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 4022 bytes --]

On Fri, Aug 21, 2020 at 04:18:03PM -0400, Alex Carter wrote:
> 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.

I think it'd be interesting to be able to repeat those tests in a
different environment. I ran multiple benchmarks in the past comparing
vhost-user-blk (Rust) vs. qemu/contrib/vhost-user-blk (C) and
vhost-user-fs (Rust) vs virtiofsd (C) and never found that performance
hit.

Much on contrary, I found Rust's zero-cost abstractions promise to
live up even with very idiomatic chunks of code (such as
vm-virtio::Queue).

> ·      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.

Sounds good. What kind of help would you need?

Thanks!
Sergio.

> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]