From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmOT0-0005Dp-5E for qemu-devel@nongnu.org; Mon, 19 May 2014 10:23:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WmOSp-00048A-QM for qemu-devel@nongnu.org; Mon, 19 May 2014 10:23:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42334) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmOSp-00047u-IN for qemu-devel@nongnu.org; Mon, 19 May 2014 10:22:51 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4JEMoUu024763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 19 May 2014 10:22:51 -0400 From: Kevin Wolf Date: Mon, 19 May 2014 16:22:21 +0200 Message-Id: <1400509360-25470-4-git-send-email-kwolf@redhat.com> In-Reply-To: <1400509360-25470-1-git-send-email-kwolf@redhat.com> References: <1400509360-25470-1-git-send-email-kwolf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] [PULL 03/22] block: vhdx - account for identical header sections List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: kwolf@redhat.com From: Jeff Cody The VHDX spec v1.00 declares that "a header is current if it is the only valid header or if it is valid and its SequenceNumber field is greater than the other header=E2=80=99s SequenceNumber field. The parser must onl= y use data from the current header. If there is no current header, then the VHDX file is corrupt." However, the Disk2VHD tool from Microsoft creates a VHDX image file that has 2 identical headers, including matching checksums and matching sequence numbers. Likely, as a shortcut the tool is just writing the header twice, for the active and inactive headers, during the image creation. Technically, this should be considered a corrupt VHDX file (at least per the 1.00 spec, and that is how we currently treat it). But in order to accomodate images created with Disk2VHD, we can safely create an exception for this case. If we find identical sequence numbers, then we check the VHDXHeader-sized chunks of each 64KB header sections (we won't rely just on the crc32c to indicate the headers are the same). If they are identical, then we go ahead and use the first one. Reported-by: Nerijus Bali=C5=ABnas Signed-off-by: Jeff Cody Signed-off-by: Kevin Wolf --- block/vhdx.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/block/vhdx.c b/block/vhdx.c index 509baaf..353c74d 100644 --- a/block/vhdx.c +++ b/block/vhdx.c @@ -473,7 +473,14 @@ static void vhdx_parse_header(BlockDriverState *bs, = BDRVVHDXState *s, } else if (h2_seq > h1_seq) { s->curr_header =3D 1; } else { - goto fail; + /* The Microsoft Disk2VHD tool will create 2 identical + * headers, with identical sequence numbers. If the headers= are + * identical, don't consider the file corrupt */ + if (!memcmp(header1, header2, sizeof(VHDXHeader))) { + s->curr_header =3D 0; + } else { + goto fail; + } } } =20 --=20 1.8.3.1