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 >>> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
