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

[Anthony Liguori <anthony@codemonkey.ws>]

On 01/27/2010 10:59 AM, Michael S. Tsirkin wrote:
> On Wed, Jan 27, 2010 at 08:07:11AM -0600, Anthony Liguori wrote:
>    
>> On 01/27/2010 03:24 AM, Michael S. Tsirkin wrote:
>>      
>>> I am not sure I agree with this sentiment.  The main issue being that
>>> macvtap doesn't exist on all kernels :).
>>>        
>> Neither does vhost ;-)  If it were just that as the difference, I'd be
>> inclined to agree, but macvtap is much better from a security PoV.
>>
>>      
>>>> Not to mention that from a user perspective, raw makes almost no sense
>>>> as it's an obscure socket protocol family.
>>>>
>>>> A user wants to do useful things like bridged networking or direct VF
>>>> assignment.  We should have -net backends that reflect things that make
>>>> sense to a user.
>>>>
>>>> Regards,
>>>>
>>>> Anthony Liguori
>>>>
>>>>          
>>> I agree to that. People don't even seem to agree whether it's a raw
>>> socket or a packet socket :) We need a better name for this option: what
>>> it really does is rely on an external device to loopback a packet to us,
>>> so how about -net loopback or -net extbridge?
>>>
>>>        
>> Specifically for VEPA, something like:
>>
>> -net extbridge,if=eth0
>>
>> or even
>>
>> -net vepa,if=eth0
>>
>> Would be fantastic.
>>      
> extbridge is IMO better.
>
>    
>> I think the best way to achieve this is to
>> introduce a small helper that gets called and can create a macvtap
>> device and hand the file descriptor back to qemu :-)  A builtin backend
>> would also be fine since we don't have the helper infrastructure.
>>      
> Excellent.
> Sridhar, this is actually not a lot of work on top of what you
> already posted.
>
>    

N.B.  I had suggested using macvtap, not raw.  In this case, the full 
syntax would be:

-net vepa,if=eth0

or

-net vepa,fd=N

where N is a macvtap fd.

For raw, I think there's a real problem wrt security.  I think it's 
important that we support running qemu as a non-privileged user.  In 
fact, this seems to be the mode libvirt is now preferring to operate in.

I think we need to re-evaluate the use of any raw socket by qemu as it's 
very dangerous from a security perspective (assuming we cannot 
introduced a "locked" raw socket mode).

Regards,

Anthony Liguori

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