From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmPM5-0002RN-CF for qemu-devel@nongnu.org; Thu, 06 Nov 2014 10:52:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XmPM0-0004P8-W7 for qemu-devel@nongnu.org; Thu, 06 Nov 2014 10:52:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40887) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmPM0-0004Ow-Or for qemu-devel@nongnu.org; Thu, 06 Nov 2014 10:52:08 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA6Fq6wS002086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 6 Nov 2014 10:52:07 -0500 Date: Thu, 6 Nov 2014 10:52:03 -0500 From: Jeff Cody Message-ID: <20141106155203.GE23802@localhost.localdomain> References: <87lhnq3iul.fsf@blackfin.pond.sub.org> <20141105110140.GC6198@noname.str.redhat.com> <87tx2csa8c.fsf@blackfin.pond.sub.org> <545B823B.50705@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <545B823B.50705@redhat.com> Subject: Re: [Qemu-devel] Image probing: how it can be insecure, and what we could do about it List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , Max Reitz , Markus Armbruster , Stefan Hajnoczi , qemu-devel@nongnu.org On Thu, Nov 06, 2014 at 03:14:19PM +0100, Eric Blake wrote: > On 11/06/2014 02:57 PM, Markus Armbruster wrote: > > >> Yes, you can override the backing file driver (backing.driver=raw should > >> do the trick). Not really user-friendly, especially with long backing > >> file chains, but it happens to be there. > >> > >> And of course, libvirt should be using it for non-qcow2 or qcow2 without > >> the backing format header extension (but doesn't yet). > > > > I'm glad it's there. Too bad libvirt doesn't use it, yet. Supports my > > point that secure usage is too hard now. > > Indeed, libvirt is still lacking on enforcing the backing type that it > probed vs. letting qemu re-probe a (possibly different) backing type. > Were libvirt to actually enforce this (that is, libvirt's default > out-of-the-box policy is to avoid all probes, and treat anything without > a type as raw) means that a user that forgets to use -obacking_fmt and > creates a chain base<-mid<-top will have the following conflicting view: > > libvirt: mid[raw]<-top[qcow2] > qemu: base[qcow2]<-mid[qcow2]<-top[qcow2] > > Right now, if the chain is only 2 deep, qemu happily boots the guest > with qcow2 format (in spite of libvirt treating mid as raw); but when > the chain is 3 deep, because libvirt failed to give SELinux permissions > to base, then qemu fails to open base, and fails to boot, but the > failure message is very cryptic. > > On the other hand, if libvirt were to ENFORCE its view that mid is raw, > by passing appropriate drive options, then qemu would always boot, but > now the top image would be visibly corrupted (treating a qcow2 file as > raw leads to MUCH different data visible in the guest) and the guest > will likely fail to boot completely, but with no error message from qemu > (rather more likely that things just hang in a 100% cpu loop in the > guest). Although the existing error message is cryptic, this new > behavior of enforcing a probed image to be raw feels like it will be > even more user-unfriendly. > > At any rate, I've certainly been working on getting libvirt to output > the ENTIRE backing chain that it has determined, rather than its old > behavior of keeping that information in memory only; this at least helps > libvirt developers diagnose bug reports ("show me what libvirt thought > your backing chain was, then go fix your XML to tell libvirt the truth > and your problem will go away, if you didn't corrupt the backing files > in the meantime with something like a 'commit' operation"). > > [I mentioned libvirt's default policy is to forbid probing and treat > untyped disks as raw; but both of those knobs can be tweaked, to either > allow probing, or treat the default type as qcow2, or both] > > > >> > >> .img is not as clear, I've seen people using it for other formats. It's > >> still a disk image, but not a raw one. > > > > Is this usage common? > > At least on my laptop - yes. I have several qcow2 files with an image > suffix of .img (perhaps because I was lazy when I created them, or > sometimes because I was quickly hacking a script to add a -fqcow2 to a > qemu-img line without changing the file name, because changing the name > would have a ripple effect on the rest of the script). But I don't know > if my usage is typical, and I also don't mind adjusting my naming > conventions to silence a warning if qemu starts getting picky about > confusing name-vs-contents issues. And if I consistently use > format=qcow2, I shouldn't be penalized with the warning, right? If you look at the QEMU "startup" documentation[1] we link to from the wiki[2], it uses .img for many of the QEMU image creation and usage examples. That leads me to think that '.img' usage as a generic extension may be fairly common. But, [1] seems outdated, as well. [1] http://en.wikibooks.org/wiki/QEMU/Images [2] http://wiki.qemu.org/Manual