From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSW20-0004bW-R1 for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:34:36 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSW1w-0004WL-Or for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:34:36 -0500 Received: from [199.232.76.173] (port=33296 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSW1w-0004VR-GQ for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:34:32 -0500 Received: from e7.ny.us.ibm.com ([32.97.182.137]:37991) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSW1v-0004GI-6G for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:34:31 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o06DSY8j026070 for ; Wed, 6 Jan 2010 08:28:34 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o06DYRKR094898 for ; Wed, 6 Jan 2010 08:34:27 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o06DYRXP010171 for ; Wed, 6 Jan 2010 11:34:27 -0200 Message-ID: <4B449162.9040107@linux.vnet.ibm.com> Date: Wed, 06 Jan 2010 07:34:26 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Planning for 0.13 References: <4B4333DF.8090303@linux.vnet.ibm.com> <20100105213350.GC30921@redhat.com> <4B43DA17.8080001@codemonkey.ws> <20100106104903.GA2248@redhat.com> <4B4483CA.2030101@linux.vnet.ibm.com> <20100106132043.GC2248@redhat.com> In-Reply-To: <20100106132043.GC2248@redhat.com> 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: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org On 01/06/2010 07:20 AM, Michael S. Tsirkin wrote: >> We can use helpers for more than just tun/tap. My current thinking for >> helpers is that they would give qemu an fd and then tell qemu how to >> work with it. Basically, use read/write vs. send/recv, whether to use a >> virtio-net header or not, etc. >> > Frankly I think this is too ambitious for 0.13, and I would like to > avoid typing features that users need today to this effort. > > Note that management still needs ability to hand fd to qemu, so we can > not require use of helpers for everyone. It's the same mechanism, no? I want to move to a single net backend that would be something like -net fd. Here are some possible invocations: -net fd,fd=3,type=tun,vnet=off -net fd,helper="/usr/libexec/qemu-net-vepa --arg-if=eth0" -net fd,fd=3,type=socket,vnet=off -net fd,fd=3,type=vhost It's really a simple thing to do and it means that we can always implement any backend outside of qemu. As part of this, I would like: -net vepa,if=eth0 To automatically translate to: -net fd,helper="/usr/libexec/qemu-net-vepa --arg-if=eth0" I'm also open to the idea of using shared libraries if people really think it's a good idea. > If the helpers are part of > qemu itself, we do not gain anything from them besides (limited) > security. But if not, we also get a protocol qemu<->helpers to > maintain. Ugh. > There really isn't much a protocol here. Helpers get handed a domain socket, then connect and send an fd via SCM_RIGHTS. They pass a string as part of that message that just happens to be equivalent to the arg string that would normally be passed to -net fd. > What I think is reasonable for 0.13, is what you posted: just allow > helper script as an alternative way to get device fd, and have qemu do > all the querying and feature negotiation exactly the way it already > does. No protocol to maintain, command line users get some extra > security, management is not affected at all. The only risk is that a new > suid binary is installed. > The whole suid binary thing is someone orthogonal to my goal here. The observation is that 99% of what people want in terms of network backends really just boils down to, here's a file descriptor, interact with it in one of a very small number of ways. >> That would allow a helper to open a raw socket, configure macvlan, and >> then hand the fd over to qemu and tell qemu how to use it. >> > Note binding to macvlan in a script buys you zero extra security > as compared to opening socket and binding in qemu. > It's not about security, it's about not making qemu the gateway to implementing arbitrarily complex network mechanisms. There's no reason qemu should have to know anything about vepa, for instance. Regards, Anthony Liguori