From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu Date: Thu, 28 Jan 2010 09:05:45 -0600 Message-ID: <4B61A7C9.7040808@codemonkey.ws> References: <4B5F54E8.3080507@codemonkey.ws> <20100127180338.GB13730@redhat.com> <4B6099E0.40101@codemonkey.ws> <201001280912.04809.arnd@arndb.de> <20100128135644.GE3776@redhat.com> <4B619BA1.9010404@codemonkey.ws> <20100128145226.GA10497@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Arnd Bergmann , Sridhar Samudrala , avi@redhat.com, markmc@redhat.com, ogerlitz@voltaire.com, kvm@vger.kernel.org, qemu-devel@vger.kernel.org, Chris Wright To: "Michael S. Tsirkin" Return-path: Received: from mail-iw0-f172.google.com ([209.85.223.172]:61643 "EHLO mail-iw0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751547Ab0A1PFt (ORCPT ); Thu, 28 Jan 2010 10:05:49 -0500 In-Reply-To: <20100128145226.GA10497@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 01/28/2010 08:52 AM, Michael S. Tsirkin wrote: > On Thu, Jan 28, 2010 at 08:13:53AM -0600, Anthony Liguori wrote: > >> On 01/28/2010 07:56 AM, Michael S. Tsirkin wrote: >> >>>> Now, the most important use case I see for the raw socket interface >>>> in qemu is to get vhost-net and the qemu user implementation to >>>> support the same feature set. If you ask for a network setup involving >>>> a raw socket and vhost-net and the kernel can support raw sockets >>>> but for some reason fails to set up vhost-net, you should have a >>>> fallback that has the exact same semantics at a possibly significant >>>> performance loss. >>>> >>>> Arnd >>>> >>>> >>> Makes sense. A simple reason you can't do vhost-net would be >>> that you are using tcg. >>> >>> >> Some good arguments have been raised in this thread. I really don't >> like making our security depend on something external to qemu that is >> not widely used or understood. >> >> That said, I'm not seeing a lot of great alternatives. I definitely >> like -net socket better than -net raw. In the absence of an >> extraordinarily clever solution, I think we may be stuck with doing this. >> > Agreed on all points. > The scenario I'm concerned about is: normal user uses libvirt to launch custom qemu instance. libvirt passes an fd of a raw socket to qemu and puts the qemu process in a restricted network namespace. user has another program running listening on a unix domain socket and does something to the qemu process that causes it to open the domain socket and send the fd it received from libvirt via SCM_RIGHTS. user now has a raw socket that is not confined to a network namespace. I'm trying to digest the disablenetwork thread right now. Basically though, what would be ideal is a /dev/net/ethN that we could open, and use read/write to send packets to and use ioctls to issue commands to do things like enable/disable offloads. I understand that raw socket is the interface we have today but I think we aren't going to be able to get around the need for a restricted file descriptor vs. using process restrictions to achieve isolation. Regards, Anthony Liguori >> Regards, >> >> Anthony Liguori >>