Re: [Qemu-devel] [PATCH] Add support for fd: protocol

[Stefan Hajnoczi <stefanha@gmail.com>]

On Mon, May 23, 2011 at 10:45 AM, Daniel P. Berrange
<berrange@redhat.com> wrote:
> On Fri, May 20, 2011 at 02:48:23PM -0400, Corey Bryant wrote:
>> sVirt provides SELinux MAC isolation for Qemu guest processes and their
>> corresponding resources (image files). sVirt provides this support
>> by labeling guests and resources with security labels that are stored
>> in file system extended attributes. Some file systems, such as NFS, do
>> not support the extended attribute security namespace, which is needed
>> for image file isolation when using the sVirt SELinux security driver
>> in libvirt.
>>
>> The proposed solution entails a combination of Qemu, libvirt, and
>> SELinux patches that work together to isolate multiple guests' images
>> when they're stored in the same NFS mount. This results in an
>> environment where sVirt isolation and NFS image file isolation can both
>> be provided.
>>
>> Currently, Qemu opens an image file in addition to performing the
>> necessary read and write operations. The proposed solution will move
>> the open out of Qemu and into libvirt. Once libvirt opens an image
>> file for the guest, it will pass the file descriptor to Qemu via a
>> new fd: protocol.
>>
>> If the image file resides in an NFS mount, the following SELinux policy
>> changes will provide image isolation:
>>
>>   - A new SELinux boolean is created (e.g. virt_read_write_nfs) to
>>     allow Qemu (svirt_t) to only have SELinux read and write
>>     permissions on nfs_t files
>>
>>   - Qemu (svirt_t) also gets SELinux use permissions on libvirt
>>     (virtd_t) file descriptors
>>
>> Following is a sample invocation of Qemu using the fd: protocol:
>>
>>     qemu -drive file=fd:4,format=qcow2
>>
>> This patch contains the Qemu code to support this solution. I would
>> like to solicit input from the libvirt community prior to starting
>> the libvirt patch.
>>
>> This patch was tested with the following formats: raw, cow, qcow,
>> qcow2, vmdk, using the fd: protocol as well as existing file name
>> support. Non-valid file descriptors were also tested.
>
> How can backing files work ?  The '-drive' syntax doesn't provide
> any way to set properties against the backing files (which may be
> nested to arbitrary depth).  AFAICT, we need to the often discussed
> -blockdev advanced syntax to be able to set a 'fd' property against
> nested backing files.  I'm not sure it is worth supporting fd: if
> we only have -drive syntax, since backing files are an important
> feature for most mgmt apps.
>
> Also, there are a few places in QEMU, where it re-opens the existing
> block driver on the fly. What is the plan for supporting this, without
> having QEMU block on waiting for libvirt to pass it a new FD ?

QEMU could ask for a file over QMP.  So you bootstrap it using fd: but
when a reopen or backing file is needed, QEMU raises a
QEVENT_BLOCK_REQUEST_FILE event.  Of course waiting around for the
reopen to complete it not ideal as it may temporarily pause the guest.

Stefan