On 01/28/2010 08:52 AM, Michael S. Tsirkin wrote:
On Thu, Jan 28, 2010 at 08:13:53AM -0600, Anthony Liguori wrote:
On 01/28/2010 07:56 AM, Michael S. Tsirkin wrote:
Now, the most important use case I see for the raw socket interface
in qemu is to get vhost-net and the qemu user implementation to
support the same feature set. If you ask for a network setup involving
a raw socket and vhost-net and the kernel can support raw sockets
but for some reason fails to set up vhost-net, you should have a
fallback that has the exact same semantics at a possibly significant
performance loss.
Arnd
Makes sense. A simple reason you can't do vhost-net would be
that you are using tcg.
Some good arguments have been raised in this thread. I really don't
like making our security depend on something external to qemu that is
not widely used or understood.
That said, I'm not seeing a lot of great alternatives. I definitely
like -net socket better than -net raw. In the absence of an
extraordinarily clever solution, I think we may be stuck with doing this.
Agreed on all points.
The scenario I'm concerned about is:
normal user uses libvirt to launch custom qemu instance. libvirt passes
an fd of a raw socket to qemu and puts the qemu process in a restricted
network namespace. user has another program running listening on a unix
domain socket and does something to the qemu process that causes it to
open the domain socket and send the fd it received from libvirt via
SCM_RIGHTS.
user now has a raw socket that is not confined to a network namespace.
I'm trying to digest the disablenetwork thread right now. Basically
though, what would be ideal is a /dev/net/ethN that we could open, and
use read/write to send packets to and use ioctls to issue commands to do
things like enable/disable offloads.
I understand that raw socket is the interface we have today but I think
we aren't going to be able to get around the need for a restricted file
descriptor vs. using process restrictions to achieve isolation.
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
