[libvirt] [PATCH RFC] Add support for QEMU vhost-user feature

[Daniel P. Berrange]

On Fri, Jun 06, 2014 at 12:11:57PM +0300, Laine Stump wrote:
> On 06/06/2014 11:49 AM, Laine Stump wrote:
> > On 06/05/2014 05:35 PM, Daniel P. Berrange wrote:
> >>  I do agree that 'vhostuser' is a somewhat
> >> QEMU specific name - at least with 'tap' this was a common terminology
> >> across multiple OS and projects. This is really a variant on 'tap'
> >> which is avoiding use of kernel devices. To perhaps we should call
> >> this new mode 'usertap' ? Or another idea would be to call it 'tapstream'
> >> eg
> > For some reason I'm more partial to "tapstream". Maybe because it
> > doesn't force any future uses to only be in userspace. But at some level
> > a name is just a name, so...
> 
> 
> I think I've changed my opinion. After looking at the high level
> description of vhost-user, I found that it isn't implemented simply
> using a stream - the stream is used by qemu to learn the location of a
> shared memory region, and the shared memory region is what is actually
> used to send/receive the packets. So it isn't just a stream.
> 
> Maybe it *is* reasonable to focus on the "this all happens in userspace"
> aspect, and simply user <interface type='user'> ? This would mean that
> the xml would look like this:
> 
>   <interface type='user'>
>     <model type='virtio'/>
>     <driver name='vhost'/>
>     <source type='unix' path='xyzzy' mode='connect'/>
>     ...
>   </interface>
> 
> Currently the "user" interface type has only one backend, which is the
> usermode networking of qemu. This would give it a 2nd backend, "vhost",
> which would be implemented by vhost-user.

No, this isn't good. type='user' specifically means that we're
applying NAT via the SLIRP ethernet munging layer. This is very
different to what vhost user is doing.

In fact looking at the QEMU code again, it says that this QEMU
net backend is in fact sending data over the chardev using the
vhost packet format. So in fact I think the choice was right
in the first patch - type='vhostuser' is a semantically good
thing to use because the data is indeed in a vhost specific
format.

> (BTW, I have a question - is only root allowed to connect to the
> vhost-user socket? Is there any selinux protection of it that needs to
> be accounted for? If not, then you may want to consider doing this to
> prevent a rogue (e.g. a qemu guest that exploits some hypothetical
> exploit in qemu to break out into the qemu process) from wreaking havoc
> with your network infrastructure. Since libvirt usually starts up qemu
> processes with a non-privileged uid, if root access is required to open
> the socket, qemu needs to be able to accept an open file descriptor for
> this rather than a path, and libvirt should be opening the socket, then
> passing the fd to qemu.)

I think this is all the same as any chardev backend - we need to apply
whatever security manager labelling  code we already have for chardevs
to this new net backend.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|