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

[Arnd Bergmann <arnd@arndb.de>]

On Wednesday 27 January 2010, Anthony Liguori wrote:
> > The raw backend can be attached to a physical device
> 
> This is equivalent to bridging with tun/tap except that it has the 
> unexpected behaviour of unreliable host/guest networking (which is not 
> universally consistent across platforms either).  This is not a mode we 
> want to encourage users to use.

It's not the most common scenario, but I've seen systems (I remember
one on s/390 with z/VM) where you really want to isolate the guest
network as much as possible from the host network. Besides PCI
passthrough, giving the host device to a guest using a raw socket
is the next best approximation of that.

Then again, macvtap will do that too, if the device driver supports
multiple unicast MAC addresses without forcing promiscous mode.

> > , macvlan
> 
> macvtap is a superior way to achieve this use case because a macvtap fd 
> can safely be given to a lesser privilege process without allowing 
> escalation of privileges.

Yes.

> >   or SR-IOV VF.
> >    
> 
> This depends on vhost-net.

Why? I don't see anything in this scenario that is vhost-net specific.
I also plan to cover this aspect in macvtap in the future, but the current
code does not do it yet. It also requires device driver changes.

>                               In general, what I would like to see for 
> this is something more user friendly that dealt specifically with this 
> use-case.  Although honestly, given the recent security concerns around 
> raw sockets, I'm very concerned about supporting raw sockets in qemu at all.
> 
> Essentially, you get worse security doing vhost-net + raw + VF then with 
> PCI passthrough + VF because at least in the later case you can run qemu 
> without privileges.  CAP_NET_RAW is a very big privilege.

It can be contained to a large degree with network namespaces. When you
run qemu in its own namespace and add the VF to that, CAP_NET_RAW
should ideally have no effect on other parts of the system (except
bugs in the namespace implementation).

	Arnd