From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33483) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xjm9v-0003OX-1f for qemu-devel@nongnu.org; Thu, 30 Oct 2014 05:36:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xjm9m-0007FK-Gk for qemu-devel@nongnu.org; Thu, 30 Oct 2014 05:36:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47233) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xjm9m-0007F3-84 for qemu-devel@nongnu.org; Thu, 30 Oct 2014 05:36:38 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9U9abvZ027996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 30 Oct 2014 05:36:37 -0400 Date: Thu, 30 Oct 2014 10:36:35 +0100 From: Kevin Wolf Message-ID: <20141030093635.GB9097@noname.str.redhat.com> References: <1414512220-19058-1-git-send-email-armbru@redhat.com> <1414512220-19058-3-git-send-email-armbru@redhat.com> <5452001E.9070907@redhat.com> <20141030092722.GB30746@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <20141030092722.GB30746@stefanha-thinkpad.redhat.com> 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: Stefan Hajnoczi Cc: qemu-devel@nongnu.org, jcody@redhat.com, Markus Armbruster , Max Reitz --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 30.10.2014 um 10:27 hat Stefan Hajnoczi geschrieben: > On Thu, Oct 30, 2014 at 10:08:46AM +0100, Max Reitz wrote: > > Also, I like Kevin's proposal/Anthony's approach a lot more because of = its > > principle. If a guest can overwrite the beginning of the image so it lo= oks > > like an image format, that's the real bug. Afterwards, anyone will reco= gnize > > that image as non-raw and they'd be correct. >=20 > No, it is not a guest bug. No, but it is a host bug. When probed, this is not content that raw can reliably store. > The guest may legitimately use raw devices that contain image format > data. Imagine tools similar to libguestfs. >=20 > It's perfectly okay for them to lay out image format data onto a raw > device. >=20 > Probing is the problem, not putting image format data onto a raw device. Agreed, that's why any restrictions only apply when probing was used to detect a raw image. If you want to do anything exotic like storing a qcow2 image for nested virt on a disk that is a raw image in the host, then making sure to pass format=3Draw shouldn't be too much. Kevin --wac7ysb48OaltWcw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJUUgajAAoJEH8JsnLIjy/WThUP/08/IZe45h0tcBzBaW9vfOoy AlwjaM7Cpdn/wQxAzW8NE/DbqcT1un7z1zc3HVGehfW+fJx5UVCelAVvYHjfJWEa aXtnpQi8HtvMpSgg1HVrIgFz9+6/BQD/JdIAfW0+tG2Eyfq8i9f/fh/604Ldh2NF iwa+TBb7+hakEL6TozGQFkr3AKJsQaXq4Kgpr6oV9bGTnoWafAoSoaRM0NLQbEhz 6wXiDsAWxh34GjXxAJgKMdBDpQKT+uZZn9u/GlaHQKez69LuD3mOLkDjGEVBQmPC vHBc0bL/lYujQV5jLWjPueVYowJ8NnH4Hf0OJwovYDNzWdKnYaTLaPPyfINrw+2p eJL11d44ePYWpV3sv7Riqfpfs4hv3z3FBwkpPu6y4PLuYcoX16Z1UZllY/ql+BBo 4SFi+Ctdb0tH9mln2aF2EiUEY9tPzWhQ+D7yZocGQ4ex2t8oxYZTy7X75w6+BXyW qXiQFNBhkcf8D8SNXXER7I8sM0+uFg+zpK5/e0/tLZ2QC8anRN4t3iUB4gxEE27X 32os94Ne2f8jyjDkzN8UIcKA63G/KfflOwhwweAP2c1I0E5pyvYHzm4tK1Ooyest b6z/XaL0uOkE6Ls6mhB8Sljw4078aPP09F+ZE8/KIJsSSZT1YnE7kaPrLfcm5XuO G8UkOdYtQwP7WR7G/ZKk =xGF4 -----END PGP SIGNATURE----- --wac7ysb48OaltWcw--