From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu Date: Thu, 28 Jan 2010 18:37:21 +0200 Message-ID: <20100128163720.GB3288@redhat.com> 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> <4B61A7C9.7040808@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:63154 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753960Ab0A1Qux (ORCPT ); Thu, 28 Jan 2010 11:50:53 -0500 Content-Disposition: inline In-Reply-To: <4B61A7C9.7040808@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Jan 28, 2010 at 09:05:45AM -0600, Anthony Liguori wrote: > 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. So actually, this is an interesting argument in favor of turning disablenetwork from per-process as it is now to per-file. > Regards, > > Anthony Liguori > >>> Regards, >>> >>> Anthony Liguori >>>