qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: Planning for 0.13
Date: Wed, 06 Jan 2010 07:34:26 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]