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

From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Sergio Lopez <slp@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Stefan Hajnoczi" <stefanha@gmail.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Oleinik, Alexander" <alxndr@bu.edu>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Dave Gilbert" <dgilbert@redhat.com>
Subject: Re: Why QEMU should move from C to Rust (clickbait alert ;))
Date: Thu, 6 Aug 2020 14:43:03 +0100	[thread overview]
Message-ID: <20200806134303.GM4159383@redhat.com> (raw)
In-Reply-To: <20200806133845.maouiwnazkjtpklr@mhamilton>

On Thu, Aug 06, 2020 at 03:38:45PM +0200, Sergio Lopez wrote:
> On Thu, Aug 06, 2020 at 01:01:30PM +0100, Daniel P. Berrangé wrote:
> > On Thu, Aug 06, 2020 at 01:51:48PM +0200, Sergio Lopez wrote:
> > > On Thu, Aug 06, 2020 at 11:24:13AM +0100, Stefan Hajnoczi wrote:
> > > <snip>
> > > > 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.
> > > > 
> > > 
> > > Having worked on Rust implementations for vhost-user-fs and
> > > vhost-user-blk, I'm 100% sold on this idea.
> > > 
> > > That said, there are a couple things that I think may help getting
> > > more people into implementing vhost-user devices in Rust.
> > > 
> > >  1. Having a reference implementation for a simple device somewhere
> > >  close or inside the QEMU source tree. I'd say vhost-user-blk is a
> > >  clear candidate, given that a naive implementation for raw files
> > >  without any I/O optimization is quite easy to read and understand.
> > > 
> > >  2. Integrating the ability to start-up vhost-user daemons from QEMU,
> > >  in an easy and portable way. I know we can always rely on daemons
> > >  like libvirt to do this for us, but I think it'd be nicer to be able
> > >  to define a vhost-user device from the command line and have QEMU
> > >  execute it with the proper parameters (BTW, Cloud-Hypervisor already
> > >  does that). This would probably require some kind of configuration
> > >  file, to be able to define which binary provides each vhost-user
> > >  device personality, but could also be a way for "sanctioning"
> > >  daemons (through the configuration defaults), and to have them adhere
> > >  to a standardized command line format.
> > 
> > This second point is such a good idea that we already have defined
> > how todo this in QEMU - see the docs/interop/vhost-user.json file.
> > This specifies metadata files that should be installed into a
> > defined location such that QEMU/libvirt/other mgmt app can locate
> > vhost-user impls for each type of device, and priortize between
> > different impls.
> 
> Nice, but AFAIK QEMU still lacks the ability to process those files
> and run the vhost-user device providers by itself. Or perhaps I just
> can't find it (?).

You're correct, thus far QEMU merely defined the standard, but thus
far libvirt is the only consumer I know of that implemented it. It
was anticipated that QEMU would implement support too but no one
has attempted it to my knowledge.

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