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

Anthony Liguori
2010-01-28T15:05:49Z

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
>>