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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
