From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [Qemu-devel] Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu Date: Wed, 27 Jan 2010 07:52:06 +0100 Message-ID: <201001270752.07037.arnd@arndb.de> References: <1264538423.24933.144.camel@w-sridhar.beaverton.ibm.com> <1264547735.24933.244.camel@w-sridhar.beaverton.ibm.com> <4B5F8379.6060607@codemonkey.ws> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Sridhar Samudrala , markmc@redhat.com, kvm@vger.kernel.org, "Michael S. Tsirkin" , qemu-devel@nongnu.org, ogerlitz@voltaire.com, avi@redhat.com To: Anthony Liguori Return-path: Received: from moutng.kundenserver.de ([212.227.126.171]:59813 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754023Ab0A0Gwd (ORCPT ); Wed, 27 Jan 2010 01:52:33 -0500 In-Reply-To: <4B5F8379.6060607@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Wednesday 27 January 2010, Anthony Liguori wrote: > > The raw backend can be attached to a physical device > > This is equivalent to bridging with tun/tap except that it has the > unexpected behaviour of unreliable host/guest networking (which is not > universally consistent across platforms either). This is not a mode we > want to encourage users to use. It's not the most common scenario, but I've seen systems (I remember one on s/390 with z/VM) where you really want to isolate the guest network as much as possible from the host network. Besides PCI passthrough, giving the host device to a guest using a raw socket is the next best approximation of that. Then again, macvtap will do that too, if the device driver supports multiple unicast MAC addresses without forcing promiscous mode. > > , macvlan > > macvtap is a superior way to achieve this use case because a macvtap fd > can safely be given to a lesser privilege process without allowing > escalation of privileges. Yes. > > or SR-IOV VF. > > > > This depends on vhost-net. Why? I don't see anything in this scenario that is vhost-net specific. I also plan to cover this aspect in macvtap in the future, but the current code does not do it yet. It also requires device driver changes. > In general, what I would like to see for > this is something more user friendly that dealt specifically with this > use-case. Although honestly, given the recent security concerns around > raw sockets, I'm very concerned about supporting raw sockets in qemu at all. > > Essentially, you get worse security doing vhost-net + raw + VF then with > PCI passthrough + VF because at least in the later case you can run qemu > without privileges. CAP_NET_RAW is a very big privilege. It can be contained to a large degree with network namespaces. When you run qemu in its own namespace and add the VF to that, CAP_NET_RAW should ideally have no effect on other parts of the system (except bugs in the namespace implementation). Arnd