Re: [Qemu-devel] [RFC 0/5] block: File descriptor passing using -open-hook-fd

[Kevin Wolf]

Am 02.05.2012 10:27, schrieb Stefan Hajnoczi:
> On Wed, May 2, 2012 at 9:20 AM, Kevin Wolf <address@hidden> wrote:
>> Am 01.05.2012 22:25, schrieb Anthony Liguori:
>>> Thanks for sending this out Stefan.
>>>
>>> On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote:
>>>> Libvirt can take advantage of SELinux to restrict the QEMU process and 
>>>> prevent
>>>> it from opening files that it should not have access to.  This improves
>>>> security because it prevents the attacker from escaping the QEMU process if
>>>> they manage to gain control.
>>>>
>>>> NFS has been a pain point for SELinux because it does not support labels 
>>>> (which
>>>> I believe are stored in extended attributes).  In other words, it's not
>>>> possible to use SELinux goodness on QEMU when image files are located on 
>>>> NFS.
>>>> Today we have to allow QEMU access to any file on the NFS export rather 
>>>> than
>>>> restricting specifically to the image files that the guest requires.
>>>>
>>>> File descriptor passing is a solution to this problem and might also come 
>>>> in
>>>> handy elsewhere.  Libvirt or another external process chooses files which 
>>>> QEMU
>>>> is allowed to access and provides just those file descriptors - QEMU cannot
>>>> open the files itself.
>>>>
>>>> This series adds the -open-hook-fd command-line option.  Whenever QEMU 
>>>> needs to
>>>> open an image file it sends a request over the given UNIX domain socket.  
>>>> The
>>>> response includes the file descriptor or an errno on failure.  Please see 
>>>> the
>>>> patches for details on the protocol.
>>>>
>>>> The -open-hook-fd approach allows QEMU to support file descriptor passing
>>>> without changing -drive.  It also supports snapshot_blkdev and other 
>>>> commands
>>>> that re-open image files.
>>>>
>>>> Anthony Liguori<address@hidden>  wrote most of these patches.  I added a
>>>> demo -open-hook-fd server and added some small fixes.  Since Anthony is
>>>> traveling right now I'm sending the RFC for discussion.
>>>
>>> What I like about this approach is that it's useful outside the block layer 
>>> and
>>> is conceptionally simple from a QEMU PoV.  We simply delegate open() to 
>>> libvirt
>>> and let libvirt enforce whatever rules it wants.
>>>
>>> This is not meant to be an alternative to blockdev, but even with blockdev, 
>>> I
>>> think we still want to use a mechanism like this even with blockdev.
>>
>> What does it provide on top?
> 
> It solves the problem of snapshot_blkdev and other operations that
> re-open files.  Using -blockdev and hotplug for image files as file
> descriptors only solves the static configuration problem, not the
> runtime problem we get with snapshot_blkdev.  That's why this approach
> is more powerful than -blockdev fd=N.

The important thing that blockdev-add must define is a QAPI type that
describes a block device. This is the same type that can be used for all
other operations as well.

In fact, live snapshots don't even require this. You just pass fd:42 (or
actually whatever the -blockdev syntax for it will be) as the new image
and use 'existing' mode. You don't even need blockdev-add for this, you
can do it with what we have today. (Warning, hack: You can even use
"live snapshots" with existing files to describe the full backing file
structure today and use only FDs. The only new thing you need there is
the fd protocol. But... don't use this.)

Kevin