From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36282) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOV4h-0007lc-Be for qemu-devel@nongnu.org; Mon, 23 May 2011 09:21:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOV4b-0002Nc-Eo for qemu-devel@nongnu.org; Mon, 23 May 2011 09:21:35 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]:32820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOV4b-0002NU-7e for qemu-devel@nongnu.org; Mon, 23 May 2011 09:21:29 -0400 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4NDEEa7031582 for ; Mon, 23 May 2011 07:14:14 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4NDLNOb141280 for ; Mon, 23 May 2011 07:21:23 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4NDQVcB010535 for ; Mon, 23 May 2011 07:26:31 -0600 Message-ID: <4DDA5F50.8050203@us.ibm.com> Date: Mon, 23 May 2011 08:21:20 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4DD6B777.9020800@us.ibm.com> <20110523094558.GA24143@redhat.com> <4DDA5804.9030403@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Add support for fd: protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Tyler C Hicks , Corey C Bryant , qemu-devel@nongnu.org On 05/23/2011 08:09 AM, Stefan Hajnoczi wrote: > On Mon, May 23, 2011 at 1:50 PM, Anthony Liguori wrote: >> 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. > > 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. QEMU doesn't actually know which caching mode the fd is in if it's being passed to it so this command doesn't make much sense. Regards, Anthony Liguori > > 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