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