From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFPxK-0008V8-Vv for qemu-devel@nongnu.org; Wed, 15 Jul 2015 12:54:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFPxJ-000861-IB for qemu-devel@nongnu.org; Wed, 15 Jul 2015 12:54:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51270) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFPxJ-00085l-BT for qemu-devel@nongnu.org; Wed, 15 Jul 2015 12:54:49 -0400 References: <20150714085742.25422.46124.malonedeb@chaenomeles.canonical.com> <20150715154236.29903.62706.malone@gac.canonical.com> From: Eric Blake Message-ID: <55A69057.9080704@redhat.com> Date: Wed, 15 Jul 2015 10:54:47 -0600 MIME-Version: 1.0 In-Reply-To: <20150715154236.29903.62706.malone@gac.canonical.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OB252XDMu511HQbpwtspw0VDWlcCmFTi9" Subject: Re: [Qemu-devel] [Bug 1474263] Re: "Image format was not specified" warning should be suppressed for the vvfat (and probably nbd) driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bug 1474263 <1474263@bugs.launchpad.net>, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OB252XDMu511HQbpwtspw0VDWlcCmFTi9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/15/2015 09:42 AM, Max Reitz wrote: > Hi, >=20 > Indeed using non-raw images should not be used over NBD. The warning > however is not superfluous, since qemu does indeed probe the image > format, so a malicious guest might write a qcow2 header into the raw > image, thus making qemu probe a qcow2 image the next time the same > configuration is used. The problem would be solved by not making qemu > probe the image format over NBD, but always assume raw; but I guess thi= s > will break existing use cases, even though they were wrong from the > start. Anyway, this is solved by explicitly specifying the image format= > to be raw, which is what the warning says. I could actually see the use of non-raw over NBD. We support nested protocols (where you can use qcow2->qcow2->file), that is, where a file contains a qcow2 file whose contents are themselves a qcow2 image. (Perhaps useful in nested guests, where the outer qcow2 layer serves a disk to an L0 guest, which in turn uses the inner layer to present a disk to an L1 guest). In such a case, opening just one layer of qcow2 for service over NBD will expose the inner qcow2 image, and connecting qemu as an NBD client with format=3Draw will directly manipulate the qcow= 2 data seen by the L0 guest, while connecting as an NBD client with format=3Dqcow2 will see the raw data seen by the L1 guest. But it's more likely to encounter this scenario with NBD, and not with vvfat. >=20 > When it comes to vvfat, we might actually put up another warning saying= > that vvfat is deprecated, but anyway: Here, too, the warning is > suppressed by doing what the warning says. Use -drive > format=3Draw,file.driver=3Dvvfat,file.dir=3D. and the warning disappear= s (or > driver=3Draw instead of format=3Draw, it's the same). >=20 > Concluding: Doing what the warning says makes it disappear (-drive > format=3Draw,=E2=80=A6), which is, not coincidentally, the warning's pu= rpose, > actually. If we want to do something about this, we would have to allow= > protocols like NBD and vvfat be able to force the default image format > used on top of them (i.e. raw). But this may break existing use cases, > at least for NBD, so I'd be wary about that. Yeah, I don't have any objections to vvfat forcing raw, but I'm very reluctant to have NBD force raw. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --OB252XDMu511HQbpwtspw0VDWlcCmFTi9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVppBXAAoJEKeha0olJ0NqIToH/A/2R5OpSNCtgFJ9tYA17nd3 4OzZ4JRbopyj+Jt9BedZJlaJSNriHANBOMTByhE2btiXlgIp+EJQJiA1DSGsmMcd XdiOlihpmP5poDxX0aopHPG2/GLalzEW5LHzOpSQIBysIz7FWm2u6yxoBhMtPAXj 9sjpepasmLW/ujpdTCEwaE0fucVy9G7B1vG5xo03mLyPIsTeLZ3MUn/nxUhRFOsF p5t6kBfly1PGxpjA/cqKuU2t6atW+6KqcMSAa/98guWumLH/oYWW/bcHj8/AviAo kY1OAWRKABcYjhm1ORAebXxiVJHq7GzssmyUF5lEcci87PqnLYV9sRicG2d1888= =L6/r -----END PGP SIGNATURE----- --OB252XDMu511HQbpwtspw0VDWlcCmFTi9--