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

[Anthony Liguori <aliguori@linux.vnet.ibm.com>]

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

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

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

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