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
