From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37027) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlxfG-0008WE-Ak for qemu-devel@nongnu.org; Wed, 05 Nov 2014 05:18:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlxfA-0003I7-CI for qemu-devel@nongnu.org; Wed, 05 Nov 2014 05:18:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37919) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlxfA-0003Hv-51 for qemu-devel@nongnu.org; Wed, 05 Nov 2014 05:18:04 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA5AI3Kf008413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 5 Nov 2014 05:18:03 -0500 Message-ID: <5459F958.7020705@redhat.com> Date: Wed, 05 Nov 2014 11:18:00 +0100 From: Eric Blake MIME-Version: 1.0 References: <5452001E.9070907@redhat.com> <20141030092722.GB30746@stefanha-thinkpad.redhat.com> <20141030093635.GB9097@noname.str.redhat.com> <20141031112423.GE10332@stefanha-thinkpad.redhat.com> <20141031115639.GD4496@noname.str.redhat.com> <878ujs1x6y.fsf@blackfin.pond.sub.org> <20141103102510.GB4437@noname.str.redhat.com> <20141103150533.GC4609@stefanha-thinkpad.redhat.com> <20141104101133.GB4119@noname.redhat.com> <20141104152544.GA28330@stefanha-thinkpad.redhat.com> <20141104153715.GG4119@noname.redhat.com> <87d292ujmg.fsf@blackfin.pond.sub.org> In-Reply-To: <87d292ujmg.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uOAH4rd9cGskLDNJeEnJ1lsRFcxTsmgXQ" Subject: Re: [Qemu-devel] [PATCH RFC 2/2] block: Warn on insecure format probing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , Kevin Wolf Cc: jcody@redhat.com, qemu-devel@nongnu.org, Stefan Hajnoczi , Max Reitz This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uOAH4rd9cGskLDNJeEnJ1lsRFcxTsmgXQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/05/2014 09:39 AM, Markus Armbruster wrote: >> Hm... In which cases does libvirt probe the image format? And is it ev= en >> consistent with qemu today? >=20 > I had a quick look at the source. Eric, please correct > misunderstandings. >=20 > Enumation type virStorageFileProbeFormat enumerates supported formats. > It has pseudo-formats VIR_STORAGE_FILE_AUTO, VIR_STORAGE_FILE_AUTO_SAFE= =2E VIR_STORAGE_FILE_AUTO is the format that libvirt assigns an image where the libvirt XML was not explicit. VIR_STORAGE_FILE_AUTO_SAFE is what the image gets reassigned to for QED (as the only format where the backing format is mandatory as part of the backing chain), which basically says: trust the backing chain if the XML omitted a type, instead of doing the normal rules of auto. >=20 > I don't understand VIR_STORAGE_FILE_AUTO_SAFE offhand. >=20 > VIR_STORAGE_FILE_AUTO means probing. Its use appears to be deprecated.= Close. It actually means: "the user did not specify a format in their XML, so it is now up to a configuration knob whether we will probe or whether we will forcefully error out and tell the user to fix their XML". The configuration knob (allow_disk_format_probing in /etc/libvirt/qemu.conf) defaults to 0 by default (error out and tell the user to fix their XML) but can be overridden to 1 by someone that knows what they are doing (probes are allowed at the user's own risk). > Actual probing happens in virStorageFileProbeFormatFromBuf(): >=20 > For all formats: > if magic and version match, pick this format >=20 > If some magic matched, but not the version: warn >=20 > For all formats: > if file name extension matches, pick this format >=20 > Pick raw. >=20 > The formats' magic, version and extension are defined in fileTypeInfo[]= =2E >=20 > If I remember correctly, libvirt has its own probing because running an= > external program just to probe is too slow. Correct. And while the libvirt probing was originally modeled after qemu, the two approaches have probably diverged a bit over time. An obvious difference: qemu only probes 512? bytes (maybe 4096?), but libvirt probes deep enough to determine the .iso file format (a 5-byte magic number at decimal offset 32769). See VIR_STORAGE_MAX_HEADER 0x8200 in src/util/virstoragefile.h. >=20 > Another reason for having its own probing might be providing a secure > replacement for QEMU's insecure probing. While that may be a possible outcome, I'm not sure it was an intentional design. >=20 >> If you can get libvirt to explicitly pass the wrong format=3D... optio= n >> because it did its own probing, we have a problem no matter what we >> change in qemu. >=20 > Yes, but that would be a libvirt problem. No excuse for us to ignore > our own problems. Correct - for the purposes of this thread, we need only figure out how to make qemu closer to being secure by default. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --uOAH4rd9cGskLDNJeEnJ1lsRFcxTsmgXQ 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 iQEcBAEBCAAGBQJUWflYAAoJEKeha0olJ0Nqkr0IALBW9xnf+xDf4gnKBk2f9CIi znINu5YtWGSYlCHMBOtgdz2kjCLq4ui/a+Nm3dbRgtPAvxrf2y7nNML8lwQVMpMx N+t2zjYdG7DLX1yzDiHbCh6120FtWp+9/0haJenfvG1tKwpxS5i7UTnPq+J5+PG3 Fd06ORnV1v/cOTfvKXGmwUfzutHd2eGrCdkvzTbhxfssZc1vWwROVlHhMzSlEi8U LAd26oiFSyfVDlH5RIKBs8r+rHZkq1DVHSzDo/dLelExSqqCgFW9diUL8/P7Y8xa aYDaowyZ2yp7Y0Dh3o6IC5O0IRzLy7yJvnbAlOOzhcjIJ9qOsoP6pbQ36oVtzrY= =xsyP -----END PGP SIGNATURE----- --uOAH4rd9cGskLDNJeEnJ1lsRFcxTsmgXQ--