From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFjE5-0002YB-Ci for qemu-devel@nongnu.org; Thu, 16 Jul 2015 09:29:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFjE1-0006xk-6a for qemu-devel@nongnu.org; Thu, 16 Jul 2015 09:29:25 -0400 Received: from mail-wg0-x22b.google.com ([2a00:1450:400c:c00::22b]:35739) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFjE0-0006wV-VL for qemu-devel@nongnu.org; Thu, 16 Jul 2015 09:29:21 -0400 Received: by wgjx7 with SMTP id x7so58500922wgj.2 for ; Thu, 16 Jul 2015 06:29:20 -0700 (PDT) Date: Thu, 16 Jul 2015 14:29:17 +0100 From: Stefan Hajnoczi Message-ID: <20150716132917.GD16984@stefanha-thinkpad.redhat.com> References: <20150714085742.25422.46124.malonedeb@chaenomeles.canonical.com> <20150715154236.29903.62706.malone@gac.canonical.com> <55A69057.9080704@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZARJHfwaSJQLOEUz" Content-Disposition: inline In-Reply-To: <55A69057.9080704@redhat.com> 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: Eric Blake Cc: Bug 1474263 <1474263@bugs.launchpad.net>, qemu-devel@nongnu.org --ZARJHfwaSJQLOEUz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 15, 2015 at 10:54:47AM -0600, Eric Blake wrote: > 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 this > > 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. >=20 > 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 qcow2 > 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. >=20 > But it's more likely to encounter this scenario with NBD, and not with > vvfat. I agree that it's perfectly okay to use non-raw on top of NBD. We allow image formats on host block devices and iSCSI LUNs. Why shouldn't they be allowed on NBD exports? Stefan --ZARJHfwaSJQLOEUz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVp7GtAAoJEJykq7OBq3PImFMIAIv4EJe/z5CFtaJlNviSe4Ox S9O++HGgjxnxhMsUMmHSsymQke8avciBdz2f63k5J/jX8LcjnusUHvaZiyYVu6Xw D0yaYRWgX6Zj+fGLxnHt2E3kls8qI7QEhaAsm+M1mZGefY+HuUTRKfuHVAMlJkK2 qMYtsEDNsg7FDRxe38qyqY7OcAKjCw/HJnOKxkUwSSMvmkOJyPDyhP6t+pLfyNCf hHj4a0fzjHuHaSEbaNsiyQFVdzpCz0+L+iFtg28eih6quN++/zRRf7zyx4R6V4zv sWZrdhtl2NzTBnpxCgZo3Z5LxrBcBxGI6zFvynklX0IuvYG2d7cVFIiyTcidqOI= =L0XN -----END PGP SIGNATURE----- --ZARJHfwaSJQLOEUz--