Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Dec 11, 2018 at 08:42:41AM +0100, Hoffmann, Gerd wrote:
>   Hi,
> 
> > Right. The main issue is that we need to make sure only
> > in-tree devices are supported.
> 
> Well, that is under debate right now, see:
> https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg04912.html

I've previously been against the idea of external plugins for QEMU,
however, that was when the plugin was something that would be dlopen'd
by QEMU. That would cause our internal ABI to be exposed to 3rd parties
which is highly undesirable, even if they were open source to comply
with the license needs.

When the plugin is a completely isolated process communicating with a
well defined protocol, it is not placing a significant burden on the
QEMU developers' ongoing maintainence, nor has problems with license
compliance. The main problem would come from debugging the combined
system as the external process is essentially a black box from QEMU's
POV. Downstream OS vendors are free to place restrictions on which
backend processes they'd be willing to support with QEMU, and upstream
is under no obligation to debug stuff beyond the QEMU boundary.

We have already accepted that tradeoff with networking by supporting
vhost-user and have externals impls like DPDK, so I don't see a
compelling reason to try to restrict it for other vhost-user backends.

> > vhost-user by design
> > is for out of tree users. It needn't be hard,
> > maybe it's enough to just make qemu launch these processes
> > as opposed to connecting to them on command line.
> 
> Not sure this is a good idea, with security being one of the motivating
> factors to move device emulation to other processes.  When libvirt
> launches the processes it can place them in separate sandboxes ...

Yep, libvirt already turns on seccomp policies which forbid QEMU from
forking/execing anything, and we have no desire to go backwards here.
Any external processes have to be launched by libvirt ahead of time.


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