Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux