|
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:1.9.1.5) 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.
Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |