All of lore.kernel.org
 help / color / mirror / Atom feed
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 13:01:30 +0100	[thread overview]
Message-ID: <20200806120130.GK4159383@redhat.com> (raw)
In-Reply-To: <20200806115148.7lz32dro645a3wv6@mhamilton>

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.


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



  reply	other threads:[~2020-08-06 12:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-06 10:24 Why QEMU should move from C to Rust (clickbait alert ;)) Stefan Hajnoczi
2020-08-06 11:08 ` Daniel P. Berrangé
2020-08-06 13:39   ` Alex Bennée
2020-08-07  9:28     ` Stefan Hajnoczi
2020-08-07  9:44   ` Stefan Hajnoczi
2020-08-06 11:51 ` Sergio Lopez
2020-08-06 12:01   ` Daniel P. Berrangé [this message]
2020-08-06 13:38     ` Sergio Lopez
2020-08-06 13:43       ` Daniel P. Berrangé
2020-08-07  9:27       ` Stefan Hajnoczi
2020-08-07  9:45         ` Stefan Hajnoczi
2020-08-07  9:39   ` Stefan Hajnoczi
  -- strict thread matches above, loose matches on Subject: below --
2020-08-21 20:18 Alex Carter
2020-08-27  8:08 ` Sergio Lopez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200806120130.GK4159383@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=alxndr@bu.edu \
    --cc=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=slp@redhat.com \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.