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

[Anthony Liguori <aliguori@us.ibm.com>]

On 05/23/2011 04:45 AM, Daniel P. Berrange 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).

This is orthogonal to having an fd: protocol.

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

That's only host CDROM AFAICT.

Regards,

Anthony Liguori

>
> Regards,
> Daniel