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

["Michael S. Tsirkin" <mst@redhat.com>]

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