[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [PATCH qemu-kvm] Add raw(af_packet) network backend
From: |
Arnd Bergmann |
Subject: |
Re: [Qemu-devel] Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu |
Date: |
Wed, 27 Jan 2010 07:52:06 +0100 |
User-agent: |
KMail/1.12.2 (Linux/2.6.33-rc5; KDE/4.3.2; x86_64; ; ) |
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