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

Michael S. Tsirkin
2010-01-28T16:50:53Z

On Thu, Jan 28, 2010 at 09:05:45AM -0600, Anthony Liguori wrote:
> 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.

So actually, this is an interesting argument in favor of
turning disablenetwork from per-process as it is now
to per-file.

> Regards,
>
> Anthony Liguori
>
>>> Regards,
>>>
>>> Anthony Liguori
>>>