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

[Stefan Hajnoczi]

On Thu, Aug 6, 2020 at 2:38 PM Sergio Lopez <slp@redhat.com> 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 (?).

How about a Python script? It can list available vhost-user programs
and their options:

  $ qemu-vhost-launcher list
  vhost-user-gpu Paravirtualized GPU with OpenGL support
  ...vhost-user-gpu --help output...
  vhost-user-blk Block device
  ...vhost-user-blk --help output...

You can write a configuration file:

  $ cat vhost-devices.conf # or yaml/toml/json?
  [blk1]
  backend=vhost-user-blk
  blk-file=/path/to/image.img

  [iso]
  backend=vhost-user-blk
  blk-file=/path/to/installer.iso
  read-only=true

And launch QEMU like this:

  $ qemu-vhost-launcher run -c vhost-devices.conf -- -M accel=kvm -m
1G -cpu host

The 'run' command builds QEMU command-line options for the devices
described in the configuration file. It launches the vhost-user device
backends and then QEMU. The QEMU vhost-user command-line options
(-chardev, -device) are appended to the command-line options.

Stefan