Re: [Qemu-devel] [PATCH] specs: mandate qcow2 v2 end-of-extensions in v3 header

[Stefan Hajnoczi]

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 <address@hidden>
> ---
>  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