Re: [Qemu-devel] Re: Planning for 0.13

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

On Wed, Jan 06, 2010 at 07:34:26AM -0600, Anthony Liguori wrote:
> On 01/06/2010 07:20 AM, Michael S. Tsirkin wrote:
>>> We can use helpers for more than just tun/tap.  My current thinking for
>>> helpers is that they would give qemu an fd and then tell qemu how to
>>> work with it.  Basically, use read/write vs. send/recv, whether to use a
>>> virtio-net header or not, etc.
>>>      
>> Frankly I think this is too ambitious for 0.13, and I would like to
>> avoid typing features that users need today to this effort.
>>
>> Note that management still needs ability to hand fd to qemu, so we can
>> not require use of helpers for everyone.
>
> It's the same mechanism, no?
> 
> I want to move to a single net backend that would be something like -net  
> fd.  Here are some possible invocations:
>
> -net fd,fd=3,type=tun,vnet=off
> -net fd,helper="/usr/libexec/qemu-net-vepa --arg-if=eth0"
> -net fd,fd=3,type=socket,vnet=off

We currently don't let users control whether vnet header
is activated in tap and IMO we are better off this way,
let qemu find out support itself.

> -net fd,fd=3,type=vhost
>
> It's really a simple thing to do and it means that we can always  
> implement any backend outside of qemu.

Look at existing backends, each of them has some quirks in qemu. It's
not realistic to expect that future backends won't need any more.

> As part of this, I would like:
>
> -net vepa,if=eth0
>
> To automatically translate to:
>
> -net fd,helper="/usr/libexec/qemu-net-vepa --arg-if=eth0"
>
> I'm also open to the idea of using shared libraries if people really  
> think it's a good idea.

What does all of this buy us?  The helpers will still need to be shipped
with qemu.

>>    If the helpers are part of
>> qemu itself, we do not gain anything from them besides (limited)
>> security.  But if not, we also get a protocol qemu<->helpers to
>> maintain. Ugh.
>>    
>
> There really isn't much a protocol here.  Helpers get handed a domain  
> socket, then connect and send an fd via SCM_RIGHTS.  They pass a string  
> as part of that message that just happens to be equivalent to the arg  
> string that would normally be passed to -net fd.

How do helpers know which arguments are legal?  Also, e.g. with
vhost-net you can open it in a helper script but you must do the rest of
the set up in qemu.


>> What I think is reasonable for 0.13, is what you posted: just allow
>> helper script as an alternative way to get device fd, and have qemu do
>> all the querying and feature negotiation exactly the way it already
>> does.  No protocol to maintain, command line users get some extra
>> security, management is not affected at all. The only risk is that a new
>> suid binary is installed.
>>    
>
> The whole suid binary thing is someone orthogonal to my goal here.  The  
> observation is that 99% of what people want in terms of network backends  
> really just boils down to, here's a file descriptor, interact with it in  
> one of a very small number of ways.

Each new backend seems to have its own quirks. Nothing seems
gained by moving handling them around.


>>> That would allow a helper to open a raw socket, configure macvlan, and
>>> then hand the fd over to qemu and tell qemu how to use it.
>>>      
>> Note binding to macvlan in a script buys you zero extra security
>> as compared to opening socket and binding in qemu.
>>    
>
> It's not about security, it's about not making qemu the gateway to  
> implementing arbitrarily complex network mechanisms.  There's no reason  
> qemu should have to know anything about vepa, for instance.
>
> Regards,
>
> Anthony Liguori

We'll still need to write all the scripts and bundle them
with qemu. So ... I fail to see 

-- 
MST