From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Na8fB-000289-HO for qemu-devel@nongnu.org; Wed, 27 Jan 2010 09:14:33 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Na8f7-00023R-Rj for qemu-devel@nongnu.org; Wed, 27 Jan 2010 09:14:33 -0500 Received: from [199.232.76.173] (port=57441 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Na8f7-00023G-M0 for qemu-devel@nongnu.org; Wed, 27 Jan 2010 09:14:29 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:56214) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Na8f7-0007mX-H6 for qemu-devel@nongnu.org; Wed, 27 Jan 2010 09:14:29 -0500 Received: by yxe26 with SMTP id 26so4836494yxe.4 for ; Wed, 27 Jan 2010 06:14:28 -0800 (PST) Message-ID: <4B604A41.1040103@codemonkey.ws> Date: Wed, 27 Jan 2010 08:14:25 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu References: <1264538423.24933.144.camel@w-sridhar.beaverton.ibm.com> <1264547735.24933.244.camel@w-sridhar.beaverton.ibm.com> <4B5F8379.6060607@codemonkey.ws> <201001270752.07037.arnd@arndb.de> In-Reply-To: <201001270752.07037.arnd@arndb.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Arnd Bergmann Cc: markmc@redhat.com, kvm@vger.kernel.org, "Michael S. Tsirkin" , qemu-devel@nongnu.org, ogerlitz@voltaire.com, avi@redhat.com, Sridhar Samudrala On 01/27/2010 12:52 AM, Arnd Bergmann wrote: > 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. > But if you care about isolation, it's the worst possible thing to do. If a guest breaks into qemu, it's one bind() away from accessing any other guests network. Using a bridge with a single interface on it is much better from an isolation perspective. >> 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). > That's a pretty big hammer to hit this problem with. QEMU should not require CAP_NET_RAW and so far has been able to avoid it quite successfully. So far, I haven't heard a compelling reason that to use raw other than bridging can be complicated to setup. If we had the equivalent of a raw socket that could be bound to a socket and then "locked" such that it could be safely handed to a non-privileged process, then it would be a different story. Regards, Anthony Liguori