From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOUsq-0003Qn-1y for qemu-devel@nongnu.org; Mon, 23 May 2011 09:09:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOUsk-0008Jf-8f for qemu-devel@nongnu.org; Mon, 23 May 2011 09:09:19 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:64469) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOUsk-0008Jb-6A for qemu-devel@nongnu.org; Mon, 23 May 2011 09:09:14 -0400 Received: by gwb19 with SMTP id 19so2440308gwb.4 for ; Mon, 23 May 2011 06:09:13 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4DDA5804.9030403@us.ibm.com> References: <4DD6B777.9020800@us.ibm.com> <20110523094558.GA24143@redhat.com> <4DDA5804.9030403@us.ibm.com> Date: Mon, 23 May 2011 14:09:13 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] Add support for fd: protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Tyler C Hicks , Corey C Bryant , qemu-devel@nongnu.org On Mon, May 23, 2011 at 1:50 PM, Anthony Liguori wrot= e: > 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: >>> >>> =A0 - A new SELinux boolean is created (e.g. virt_read_write_nfs) to >>> =A0 =A0 allow Qemu (svirt_t) to only have SELinux read and write >>> =A0 =A0 permissions on nfs_t files >>> >>> =A0 - Qemu (svirt_t) also gets SELinux use permissions on libvirt >>> =A0 =A0 (virtd_t) file descriptors >>> >>> Following is a sample invocation of Qemu using the fd: protocol: >>> >>> =A0 =A0 qemu -drive file=3Dfd:4,format=3Dqcow2 >>> >>> 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 ? =A0The '-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. The host page cache on|off option also uses it because fcntl(2) cannot change O_DIRECT. Actually for Linux it may be doable with open('/proc/fd/', flags ^ O_DIRECT) and on other hosts SELinux does not exist. On the other hand fcntl(2) should really support changing O_DIRECT - only that there is not much incentive to fix Linux if other OSes don't support it either (and older Linux kernels also require workarounds). Stefan