qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Eric Blake <eblake@redhat.com>
Cc: kwolf@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com
Subject: Re: [Qemu-devel] [PATCH] specs: mandate qcow2 v2 end-of-extensions in v3 header
Date: Tue, 17 Dec 2013 15:04:39 +0100	[thread overview]
Message-ID: <20131217140439.GB2708@stefanha-thinkpad.redhat.com> (raw)
In-Reply-To: <1387241528-28885-1-git-send-email-eblake@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 <eblake@redhat.com>
> ---
>  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

      reply	other threads:[~2013-12-17 14:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-17  0:52 [Qemu-devel] [PATCH] specs: mandate qcow2 v2 end-of-extensions in v3 header Eric Blake
2013-12-17 14:04 ` Stefan Hajnoczi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131217140439.GB2708@stefanha-thinkpad.redhat.com \
    --to=stefanha@gmail.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).