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

[Daniel P . Berrangé]

On Thu, Aug 06, 2020 at 11:24:13AM +0100, Stefan Hajnoczi wrote:

...snip...

I broadly agree with the points about why Rust is desirable as
a language for QEMU.

> How can we change programming language?
> ------------------------------------------------------------
> When I checked in 2018 QEMU was 1.5 million lines of code. It has
> grown since then. Moving a large codebase to a new programming
> language is extremely difficult. If people want to convert QEMU to
> Rust that would be great, but I personally don't have the appetite to
> do it because I think the integration will be messy, result in a lot
> of duplication, and there is too much un(der)maintained code that is
> hard to convert.
> 
> The reason I am writing this post is because device emulation, the
> main security attack surface for VMMs, can be done in a separate
> program. That program can be written in any language and this is where
> Rust comes in. For vhost devices it is possible to write Rust device
> backends today and I hope this will become the default approach to
> writing new devices.
> 
> For non-vhost devices the vfio-user project is working on an interface
> out-of-process device emulation. It will be possible to implement
> devices in Rust there too.

I guess this dovetails into our view of security bug classification.
Stuff that affects virtualization use cases is security critical,
while stuff that affects emulation is NOT security critical.

With this in mind, it is not a priority to convert the whole of
QEMU to Rust. The priority is the subset that affects virtualization
use cases. It is a much more tractable problem if we're looking at
creating rust based vhost-user / vfio-user, only for the devices
that are commonly used for KVM with modern OS, and ignore the many
100's of devices that are only there for emulation or foir legacy OS.


> If you are implementing new device emulation code please consider
> doing it in Rust!

Yes, but I think we'll need put in significant effort to guide / assist
people in taking this direction, and think about what it means for the
future of QEMU as a brand and GIT repo.

In many ways it is a good thing if the Rust vhost-user impls are
all in their own standalone git repos. They're likely to be independent
codebases, so there's little compelling reason to force them into the
QEMU git, where they'll have to use QEMU workflow, and QEMU release
cycle. They're better off free from QEMU where they can choose to adopt
modern development practices like GitLab merge requests if they
desire and release on a more frequent cycle than QEMU's 3-times a
year, etc. Would also make them more appealing for use by alternative
non-QEMU userspaces for KVM.

The downside is that QEMU git would only contain the "legacy" builtin
C impls of the devices, and all the "recommended" modern Rust impls
would be elsewhere. Essentially QEMU would no longer be a self-contained
provider of the complete solution. Many parts would be disaggregated,
and users now have the burden of finding all the right pieces to build
the best solution. We've already seen this to some extent with existing
vhost-user impls, but it feels like we'd be pushing towards that as a
more general model for the future which would amplify problems we've
largely been able to ignore upto now.

I'm not sure what a good answer here is. Perhaps QEMU could try to
become more of brand for an umbrella project that covers multiple
independant repos ? eg create new repos under gitlab.com/qemu-project/
but allow them to work fairly independantly from the main qemu.git ?
That way we can more easily promote a collection of QEMU repos as
showing the recommended architecture, without forcing everything
into qemu.git. We can leverage the QEMU website, wiki and documentation
in general to showcase the overall solution, while still letting the
pieces develop independently.

> Conclusion
> ---------------
> Most security bugs in QEMU today are C programming bugs. Switching to
> a safer programming language will significantly reduce security bugs
> in QEMU. Rust is now mature and proven enough to use as the language
> for device emulation code. Thanks to vhost-user and vfio-user using
> Rust for device emulation does not require a big conversion of QEMU
> code, it can simply be done in a separate program. This way attack
> surfaces can be written in Rust to make them less susceptible to
> security bugs going forward.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|