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: Wed, 27 Jan 2010 11:07:45 -0600 Message-ID: <4B6072E1.7030702@codemonkey.ws> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sridhar Samudrala , avi@redhat.com, markmc@redhat.com, ogerlitz@voltaire.com, kvm@vger.kernel.org, qemu-devel@vger.kernel.org To: "Michael S. Tsirkin" Return-path: Received: from mail-fx0-f215.google.com ([209.85.220.215]:47630 "EHLO mail-fx0-f215.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755502Ab0A0RHw (ORCPT ); Wed, 27 Jan 2010 12:07:52 -0500 In-Reply-To: <20100127165909.GA13260@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. In this case, the full syntax would be: -net vepa,if=eth0 or -net vepa,fd=N 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). Regards, Anthony Liguori >> Regards, >> >> Anthony Liguori >>