[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options

From: Anthony Liguori
Subject: [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options
Date: Sun, 28 Feb 2010 10:08:26 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

On 02/27/2010 01:44 PM, Michael S. Tsirkin wrote:
and it doesn't
support all of the features of userspace virtio.  Since it's in upstream
Linux without supporting all of the virtio-net features, it's something
we're going to have to deal with for a long time.
Speaking of vlan filtering etc?  It's just a matter of time before it
supports all interesting features. Kernel support is there in net-next
already, userspace should be easy too. I should be able to code it up
once I finish bothering about upstream merge (hint hint :)).

:-) As I've said in the past, I'm willing to live with -net tap,vhost but I really think -net vhost would be better in the long run.

The only two real issues I have with the series is the ring address mapping stability and the duplicated slot management code. Both have security implications so I think it's important that they be addressed. Otherwise, I'm pretty happy with how things are.

Furthermore, vhost reduces a virtual machine's security.  It offers an
impressive performance boost (particularly when dealing with 10gbit+
networking) but for a user that doesn't have such strong networking
performance requirements, I think it's reasonable for them to not want
to make a security trade off.
It's hard for me to see how it reduces VM security. If it does, it's
not by design and will be fixed.

If you have a bug in vhost-net (would never happen of course) then it's a host-kernel exploit whereas if we have a bug in virtio-net userspace, it's a local user exploit. We have a pretty robust architecture to deal with local user exploits (qemu can run unprivilieged, SELinux enforces mandatory access control) but a host-kernel can not be protected against.

I'm not saying that we should never put things in the kernel, but there's definitely a security vs. performance trade off here.


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]