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: Wed, 27 Jan 2010 19:25:36 +0200 Message-ID: <20100127172536.GD13260@redhat.com> References: <1264538423.24933.144.camel@w-sridhar.beaverton.ibm.com> <4B5F54E8.3080507@codemonkey.ws> <4B5F5594.6080006@codemonkey.ws> <20100127092451.GC3476@redhat.com> <4B60488F.5020506@codemonkey.ws> <20100127165909.GA13260@redhat.com> <4B6072E1.7030702@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sridhar Samudrala , avi@redhat.com, markmc@redhat.com, ogerlitz@voltaire.com, kvm@vger.kernel.org, qemu-devel@vger.kernel.org To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:34855 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753596Ab0A0R3A (ORCPT ); Wed, 27 Jan 2010 12:29:00 -0500 Content-Disposition: inline In-Reply-To: <4B6072E1.7030702@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jan 27, 2010 at 11:07:45AM -0600, Anthony Liguori wrote: > On 01/27/2010 10:59 AM, Michael S. Tsirkin wrote: >> On Wed, Jan 27, 2010 at 08:07:11AM -0600, Anthony Liguori wrote: >> >>> On 01/27/2010 03:24 AM, Michael S. Tsirkin wrote: >>> >>>> I am not sure I agree with this sentiment. The main issue being that >>>> macvtap doesn't exist on all kernels :). >>>> >>> Neither does vhost ;-) If it were just that as the difference, I'd be >>> inclined to agree, but macvtap is much better from a security PoV. >>> >>> >>>>> Not to mention that from a user perspective, raw makes almost no sense >>>>> as it's an obscure socket protocol family. >>>>> >>>>> A user wants to do useful things like bridged networking or direct VF >>>>> assignment. We should have -net backends that reflect things that make >>>>> sense to a user. >>>>> >>>>> Regards, >>>>> >>>>> Anthony Liguori >>>>> >>>>> >>>> I agree to that. People don't even seem to agree whether it's a raw >>>> socket or a packet socket :) We need a better name for this option: what >>>> it really does is rely on an external device to loopback a packet to us, >>>> so how about -net loopback or -net extbridge? >>>> >>>> >>> Specifically for VEPA, something like: >>> >>> -net extbridge,if=eth0 >>> >>> or even >>> >>> -net vepa,if=eth0 >>> >>> Would be fantastic. >>> >> extbridge is IMO better. >> >> >>> I think the best way to achieve this is to >>> introduce a small helper that gets called and can create a macvtap >>> device and hand the file descriptor back to qemu :-) A builtin backend >>> would also be fine since we don't have the helper infrastructure. >>> >> Excellent. >> Sridhar, this is actually not a lot of work on top of what you >> already posted. >> >> > > N.B. I had suggested using macvtap, not raw. Well, this is an implementation detail :) In fact, I don't have any objections to using macvtap. As I tried to hint, macvtap doesn't seem to exist in any Linux yet, packet sockets have been supported since ages. So we might want to support packet sockets at least optionally as a backend for extbridge. > In this case, the full > syntax would be: > > -net vepa,if=eth0 > > or > > -net vepa,fd=N I still hope it's extbridge, vepa is an acronym that will likely not be known for 99% of users. > where N is a macvtap fd. > > For raw, I think there's a real problem wrt security. I think it's > important that we support running qemu as a non-privileged user. In > fact, this seems to be the mode libvirt is now preferring to operate in. > > I think we need to re-evaluate the use of any raw socket by qemu as it's > very dangerous from a security perspective (assuming we cannot > introduced a "locked" raw socket mode). As was pointed out on netdev and elsewhere this seems to be what namespaces/selinux are there for. Can qemu be run within a namespace and if yes would that address your concerns? Security is probably a wrong reason to use character devices: they are much more likely to have security problems than standard interfaces. Ease of setup/compatibility with tap would be a better reason. > Regards, > > Anthony Liguori > >>> Regards, >>> >>> Anthony Liguori >>>