From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VZA3y-0002RI-SL for mharc-grub-devel@gnu.org; Wed, 23 Oct 2013 21:50:14 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58038) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZA3r-0002PP-Jy for grub-devel@gnu.org; Wed, 23 Oct 2013 21:50:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZA3m-0006Ym-87 for grub-devel@gnu.org; Wed, 23 Oct 2013 21:50:07 -0400 Received: from mail-ee0-x229.google.com ([2a00:1450:4013:c00::229]:40088) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZA3m-0006X9-0X for grub-devel@gnu.org; Wed, 23 Oct 2013 21:50:02 -0400 Received: by mail-ee0-f41.google.com with SMTP id d49so773625eek.0 for ; Wed, 23 Oct 2013 18:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=WkBdN1CJs/o2FoMD/YJ3aWGWuZUfy6UEmA72AJZ/aCU=; b=fQ8FVpmJ72cSOJJ4PyFp/UELpS8ju8JQamOhUGqJvLIbqd2CVuo64ifRCRK9R12A+8 v8KonJuv2mxRySyT8FffLEBuwydjjolqrvRIRfR3SKzCVBj0v4U4xzgySN04Qhi4X2wr 5E5gBwGRMuPvrgOF9m+KCdi65TsSPKPbNBbfukbeVdZflj8HBtw4prHvXbXB7KAzQlah Y2yI7T0Gilh7JiSwhzSIO+2k/2N39lgNubfJESOl5/ayxmKv2sI9ZdO8A2BDLQTyWtKL qy5BOciIr+bCoJOtq0n1xmLq6NF6oS2crESDtEzYfNVnNoMihcHmi+CQjo9tqt6ZcoNP oQUQ== X-Received: by 10.15.45.8 with SMTP id a8mr232359eew.1.1382579400918; Wed, 23 Oct 2013 18:50:00 -0700 (PDT) Received: from [192.168.1.16] (31-249.1-85.cust.bluewin.ch. [85.1.249.31]) by mx.google.com with ESMTPSA id k7sm77031939eeg.13.2013.10.23.18.50.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 18:50:00 -0700 (PDT) Message-ID: <52687CC7.4010605@gmail.com> Date: Thu, 24 Oct 2013 03:49:59 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: grub mishandles corrupt/missing primary GPT References: <9DB3EF6D-6E26-4A9F-BB2D-07CCEF378D7A@colorremedies.com> In-Reply-To: <9DB3EF6D-6E26-4A9F-BB2D-07CCEF378D7A@colorremedies.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2HRMAHMXCFOEUPCNLUGDO" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::229 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 01:50:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2HRMAHMXCFOEUPCNLUGDO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 24.10.2013 03:38, Chris Murphy wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=3D1022743 >=20 > Gist is, starting with a disk with valid PMBR, primary GPT, and backup > GPT, if I zero LBA 2, I can no longer boot from the disk. I get a grub > rescue prompt. >=20 > Instead, if I merely corrupt a portion of the first partitiontypeguid t= o > mimic corruption, I can still boot, whereas this primary GPT fails > checksums with both gdisk and parted.=20 >=20 > This tells me that GRUB isn't checking for the validity of the primary > GPT. And GRUB doesn't ever use the backup GPT. >=20 > Expected behavior is GRUB should check if the MBR is a PMBR (1st and > only entry is type 0xEE) There are so called "hybrid" disks which we have to treat as GPT > and if not then consider the disk MBR. If it is > PMBR, check validity of the primary GPT header+table, if valid use it. > If invalid, check validity of backup GPT header+table, if valid use it.= > If invalid, fail. partmap module is size-critical and CRC32 verification is pretty big. There are 3 problems with backup header: 1) Backup header would be preserved even when primary is deliberately reformatted and if we use it then we'll use it even on disks where we should use newly-created MBR 2) The disk size isn't always known (loopback over network device, ieee1275 disks and CD-ROMs, possibly others) 3) There are some weird scenarios with USB enclosures "forgetting" last disk sectors which leads to partition having two different back-headers. Consider following scenario: One formats with enclosure, then puts disk natively and moves backup headers to real end of disk and later modifies partition table. Then puts disk in enclosure again and then backup has older table. Do you have ways to handle this? Why primary would be corrupted in first place? >=20 > Chris Murphy >=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >=20 ------enig2HRMAHMXCFOEUPCNLUGDO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREKAAYFAlJofMcACgkQNak7dOguQgnIvwD/eXTaqOjuvIuT7ExooPr2tako h0LoNmyEsLElgP5+IqUBAMJy1xTEShASyO1d14cAgrWZC/SJOH50bCgjD88aRgQN =mvdx -----END PGP SIGNATURE----- ------enig2HRMAHMXCFOEUPCNLUGDO--