From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmNpa-0006uf-Un for qemu-devel@nongnu.org; Thu, 06 Nov 2014 09:14:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XmNpQ-0006HR-6u for qemu-devel@nongnu.org; Thu, 06 Nov 2014 09:14:34 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47641) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmNpP-0006Gy-Vs for qemu-devel@nongnu.org; Thu, 06 Nov 2014 09:14:24 -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 sA6EEMXD024843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 6 Nov 2014 09:14:23 -0500 Message-ID: <545B823B.50705@redhat.com> Date: Thu, 06 Nov 2014 15:14:19 +0100 From: Eric Blake MIME-Version: 1.0 References: <87lhnq3iul.fsf@blackfin.pond.sub.org> <20141105110140.GC6198@noname.str.redhat.com> <87tx2csa8c.fsf@blackfin.pond.sub.org> In-Reply-To: <87tx2csa8c.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0xg4UBWFm219Q9lgHBVJ9HEn46S8RmMhm" 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: Markus Armbruster , Kevin Wolf Cc: Jeff Cody , qemu-devel@nongnu.org, Stefan Hajnoczi , Max Reitz This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0xg4UBWFm219Q9lgHBVJ9HEn46S8RmMhm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/06/2014 02:57 PM, Markus Armbruster wrote: >> Yes, you can override the backing file driver (backing.driver=3Draw sh= ould >> 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 witho= ut >> the backing format header extension (but doesn't yet). >=20 > 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. >=20 > 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=3Dqcow2, I shouldn't be penalized with the warning, right? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --0xg4UBWFm219Q9lgHBVJ9HEn46S8RmMhm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJUW4I8AAoJEKeha0olJ0Nq550H/0UktNeQxa4c71kuxlg2Rrcp 5/mSGOxG8WqeurQmy2DcoQtPD3hDggDU+uP3u6shMNsOIsdcpaVt51ZAeDT9xn3L XY9WK4pU559lanENfwtYkiw2V9XfIz2FZoOIJuq8awwAYYSLF5yvzntveeM1AuYd IDrIYdNLHYChke8wy/+vuQzKzWlnLQyzpT+/A9MchyBOUKRrEetT3jyvSRkGJ4JW w/Ivg6ooA4qOft9rXIPdm48gEz2VwceSzK9FihdQuF2NdqthjcjIUoHeBGM5+R4R XfRUPMVHEaPlgN5s36gQ2PGmUEAcbBLpbqjmlkkdsRg10UQQVXYrzHBamzgk5G8= =RQ/Y -----END PGP SIGNATURE----- --0xg4UBWFm219Q9lgHBVJ9HEn46S8RmMhm--