From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nllh4-0000th-Gd for qemu-devel@nongnu.org; Sun, 28 Feb 2010 11:08:34 -0500 Received: from [199.232.76.173] (port=45350 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nllh3-0000sQ-Ri for qemu-devel@nongnu.org; Sun, 28 Feb 2010 11:08:34 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nllh0-0007uB-Pm for qemu-devel@nongnu.org; Sun, 28 Feb 2010 11:08:33 -0500 Received: from mail-gy0-f173.google.com ([209.85.160.173]:47624) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nllh0-0007u6-Gn for qemu-devel@nongnu.org; Sun, 28 Feb 2010 11:08:30 -0500 Received: by gyh4 with SMTP id 4so775256gyh.4 for ; Sun, 28 Feb 2010 08:08:29 -0800 (PST) Message-ID: <4B8A94FA.5020000@codemonkey.ws> Date: Sun, 28 Feb 2010 10:08:26 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <886ef6ffeb6748f6dc4fe5431f71cb12bb74edc9.1267122331.git.mst@redhat.com> <4B86D3CF.4020601@codemonkey.ws> <20100226145155.GC23359@redhat.com> <4B87E755.9000707@codemonkey.ws> <20100227194418.GB26389@redhat.com> In-Reply-To: <20100227194418.GB26389@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: amit.shah@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com 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