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

[Alex Bennée]

Daniel P. Berrangé <berrange@redhat.com> writes:

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

I'm definitely interested in vhost-user daemons in Rust. The one I've
been writing so far has been tried to be a minimal POSIX base without
including QEMU utility functions but I'm sure it would be nicer to start
with a clean standalone Rust library.

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

I think there would be scope for a vhost-user-daemon repo with multiple
reference implementations.

So has any vhost-user stuff been prototyped in Rust yet?

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


-- 
Alex Bennée