From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsvGV-0006KH-Ql for qemu-devel@nongnu.org; Tue, 17 Dec 2013 09:05:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VsvGN-0001zN-CG for qemu-devel@nongnu.org; Tue, 17 Dec 2013 09:04:51 -0500 Received: from mail-ea0-x235.google.com ([2a00:1450:4013:c01::235]:64885) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsvGN-0001zJ-5B for qemu-devel@nongnu.org; Tue, 17 Dec 2013 09:04:43 -0500 Received: by mail-ea0-f181.google.com with SMTP id m10so2889140eaj.26 for ; Tue, 17 Dec 2013 06:04:42 -0800 (PST) Date: Tue, 17 Dec 2013 15:04:39 +0100 From: Stefan Hajnoczi Message-ID: <20131217140439.GB2708@stefanha-thinkpad.redhat.com> References: <1387241528-28885-1-git-send-email-eblake@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1387241528-28885-1-git-send-email-eblake@redhat.com> Subject: Re: [Qemu-devel] [PATCH] specs: mandate qcow2 v2 end-of-extensions in v3 header List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: kwolf@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com On Mon, Dec 16, 2013 at 05:52:08PM -0700, Eric Blake wrote: > At least libvirt 0.10.2 has a bug where it can be provoked > into attempting to search for extension headers (in particular, > the backing file format header) without first validating that > a particular file is qcow2 version 2. Fortunately, to date, > this probe always ends early when feeding a version 3 file to > this version of libvirt: the version 2 file treats bytes 72-75 > as the magic number for an extension header, while version 3 > treats it as the upper half of the 8-byte incompatible_features > field. As long as we don't have that many incompatible > features, these bytes are always 0, which aligns with the > end-of-extension magic number, and forces the broken libvirt to > quit looking for other headers in its v2 view of the world. > But as future extensions may conceivably contain contents that > would cause broken libvirt to misbehave if it kept looking for > headers, it is better to codify this into the qcow2 v3 > specification. > > No qemu code changes are required by this doc patch - anyone > setting bits within bytes 72-75 already causes the file to > be rejected as an invalid qcow2 v3 file by all current v3 > implementations. And cutting the field from 8 bytes to 4 > has no real serious consequence - if we ever have that many > incompatible bits in the future, we can always declare bit 31 > as an incompatible feature bit that says where else to look > for any further needed incompatible feature bits. > > [If we had a time machine, I would propose that we make bytes > 72-79 of the version 3 header resemble a well-formed extension > header of version 2, and move incompatible_features to offset > 80 or later - but that's what we get for having hindsight.] > > * docs/specs/qcow2.txt: Formally define what happened to be an > accidental feature protecting us from buggy v2 clients. > > Signed-off-by: Eric Blake > --- > docs/specs/qcow2.txt | 20 ++++++++++++++++++-- > 1 file changed, 18 insertions(+), 2 deletions(-) I see this as a libvirt bug that should be fixed in a libvirt stable release. The libvirt bug needs to be fixed anyway, let's not add quirks to the qcow2 spec. Kevin is on holiday, he may want to discuss more when he returns. Stefan