On Mon, May 23, 2011 at 10:45 AM, Daniel P. Berrange <berra...@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
