From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VZ9tJ-00017Y-Rd for mharc-grub-devel@gnu.org; Wed, 23 Oct 2013 21:39:13 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZ9tB-00017P-8f for grub-devel@gnu.org; Wed, 23 Oct 2013 21:39:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZ9t3-0003RQ-Qf for grub-devel@gnu.org; Wed, 23 Oct 2013 21:39:05 -0400 Received: from [50.115.112.57] (port=24890 helo=slmp-550-94.slc.westdc.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZ9t3-0003R5-Ii for grub-devel@gnu.org; Wed, 23 Oct 2013 21:38:57 -0400 Received: from c-67-165-243-162.hsd1.co.comcast.net ([67.165.243.162]:60814 helo=[192.168.1.126]) by slmp-550-94.slc.westdc.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VZ9t0-001C7D-IX for grub-devel@gnu.org; Wed, 23 Oct 2013 19:38:54 -0600 From: Chris Murphy Content-Type: multipart/alternative; boundary="Apple-Mail=_F05CDBCE-722A-4DDF-81E7-E6DBB8A7A6BC" Subject: grub mishandles corrupt/missing primary GPT Message-Id: <9DB3EF6D-6E26-4A9F-BB2D-07CCEF378D7A@colorremedies.com> Date: Wed, 23 Oct 2013 19:38:52 -0600 To: The development of GNU GRUB Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - slmp-550-94.slc.westdc.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - colorremedies.com X-Get-Message-Sender-Via: slmp-550-94.slc.westdc.net: authenticated_id: whatever@colorremedies.com X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 50.115.112.57 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:39:12 -0000 --Apple-Mail=_F05CDBCE-722A-4DDF-81E7-E6DBB8A7A6BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii https://bugzilla.redhat.com/show_bug.cgi?id=3D1022743 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. Instead, if I merely corrupt a portion of the first partitiontypeguid to = mimic corruption, I can still boot, whereas this primary GPT fails = checksums with both gdisk and parted.=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. Expected behavior is GRUB should check if the MBR is a PMBR (1st and = only entry is type 0xEE) 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. Chris Murphy= --Apple-Mail=_F05CDBCE-722A-4DDF-81E7-E6DBB8A7A6BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii https://bug= zilla.redhat.com/show_bug.cgi?id=3D1022743

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.

Instead, if I merely corrupt a portion = of the first partitiontypeguid to mimic corruption, I can still boot, = whereas this primary GPT fails checksums with both gdisk and = parted.

This tells me that GRUB isn't = checking for the validity of the primary GPT. And GRUB doesn't ever use = the backup GPT.

Expected behavior is GRUB = should check if the MBR is a PMBR (1st and only entry is type 0xEE) 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.

Chris Murphy

= --Apple-Mail=_F05CDBCE-722A-4DDF-81E7-E6DBB8A7A6BC-- 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-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VZBGw-0002cR-Qn for mharc-grub-devel@gnu.org; Wed, 23 Oct 2013 23:07:42 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38448) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZBGo-0002cE-NF for grub-devel@gnu.org; Wed, 23 Oct 2013 23:07:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZBGh-0007Gi-C6 for grub-devel@gnu.org; Wed, 23 Oct 2013 23:07:34 -0400 Received: from [50.115.112.57] (port=12969 helo=slmp-550-94.slc.westdc.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZBGh-0007FV-2Z for grub-devel@gnu.org; Wed, 23 Oct 2013 23:07:27 -0400 Received: from c-67-165-243-162.hsd1.co.comcast.net ([67.165.243.162]:61211 helo=[192.168.1.126]) by slmp-550-94.slc.westdc.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VZBGc-001eUX-MT for grub-devel@gnu.org; Wed, 23 Oct 2013 21:07:22 -0600 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: grub mishandles corrupt/missing primary GPT From: Chris Murphy In-Reply-To: <52687CC7.4010605@gmail.com> Date: Wed, 23 Oct 2013 21:07:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6400C778-E3A3-42FD-ABF7-E15DF635FC40@colorremedies.com> References: <9DB3EF6D-6E26-4A9F-BB2D-07CCEF378D7A@colorremedies.com> <52687CC7.4010605@gmail.com> To: The development of GNU GRUB X-Mailer: Apple Mail (2.1510) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - slmp-550-94.slc.westdc.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - colorremedies.com X-Get-Message-Sender-Via: slmp-550-94.slc.westdc.net: authenticated_id: whatever@colorremedies.com X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 50.115.112.57 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 03:07:42 -0000 Thanks for the response: On Oct 23, 2013, at 7:49 PM, Vladimir '=CF=86-coder/phcoder' Serbinenko = wrote: > 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 = to >> 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 While technically a violation of the UEFI spec, I think this can be = worked around by considering the disk GPT if the first entry in the MBR = is type 0xEE. I don't know of a hybrid MBR implementation where an entry = other than the first is 0xEE.=20 But if there is no 0xEE entry at all, this is identical to a formerly = GPT disk repartitioned as MBR by a utility that doesn't know anything = about GPT, and thus doesn't erase the stale GPT data - and therefore = must be treated as MBR. >> 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. So perhaps this test is difficult because it's GPT on BIOS, with a = limited space BIOS boot partition. However, I think on UEFI computers = this should still work with one valid GPT, rather than not boot at all. = There's a lot more space for this there. > 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 Both primary and backup GPTs are preserved in this case since the = primary is in LBA 1 and 2, and only LBA 0 is overwritten with the new = MBR. UEFI spec says if the MBR signature of 0xaa55 is intact, and there isn't = an 0xEE entry, and the partition entries are rational (physically on = disk and don't overlap), then the two GPTs are considered stale and the = disk is MBR. > 2) The disk size isn't always known (loopback over network device, > ieee1275 disks and CD-ROMs, possibly others) The primary header contains the location of the backup GPT. If the = header is sufficiently corrupt, and the backup GPT can't be located, = then that's the same as an invalid backup GPT, and in that case fail. My point is we shouldn't fail when there is a valid locatable backup = GPT. The whole point of having a second GPT is obviated with the current = behavior. > 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. I don't think we can work around this kind of hardware vendor sabotage. = If it looks like a valid GPT, but is actually stale, if it's used and = contains incorrect information, then boot fails. Better to try than not = try at all. >=20 > Do you have ways to handle this? > Why primary would be corrupted in first place? It's certainly uncommon. A Google search: corrupt "primary gpt" only = turns up 1900 results. But it is possible. And this isn't the only mishandling I'm finding, so it's not like GRUB = is unique. In fact just now by changing only a single byte in the = primary GPT table (I changed the E to an F in the BIOS boot partition = type UUID), the kernel suddenly has no idea what disklabel the disk is, = and fails to mount rootfs. So I need to track that down too, but it = seems like it knows the primary GPT table is corrupt, but then fails to = use the backup GPT for some reason. An argument against GRUB doing all of this work: maybe the bootloader = should be able to blindly trust the primary GPT table with no validity = checks? And instead rely on (presently non-existent) checks by the = underlying OS to fixi this problem? Something like an fsck_gpt, seeing = as nothing else is in a good position to both check and fix such GPTs = other than a partition tool. The UEFI spec says "Software should ask a user for confirmation before = restoring the primary GPT" and yet it also requires the unspecified = software fix the primary GPT if corrupt. The spec actually uses the word = "must". So per usual, the spec has rather lofty demands. Chris Murphy= From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VZL8D-0001x6-6N for mharc-grub-devel@gnu.org; Thu, 24 Oct 2013 09:39:21 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42853) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZL83-0001wt-U2 for grub-devel@gnu.org; Thu, 24 Oct 2013 09:39:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZL7w-0001Uy-JQ for grub-devel@gnu.org; Thu, 24 Oct 2013 09:39:11 -0400 Received: from mail.csclub.uwaterloo.ca ([129.97.134.52]:53888) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZL7w-0001Uh-Dj for grub-devel@gnu.org; Thu, 24 Oct 2013 09:39:04 -0400 Received: from caffeine.csclub.uwaterloo.ca (caffeine.csclub.uwaterloo.ca [129.97.134.17]) by mail.csclub.uwaterloo.ca (Postfix) with SMTP id 503B82DF87 for ; Thu, 24 Oct 2013 09:39:02 -0400 (EDT) Received: by caffeine.csclub.uwaterloo.ca (sSMTP sendmail emulation); Thu, 24 Oct 2013 09:39:02 -0400 From: "Lennart Sorensen" Date: Thu, 24 Oct 2013 09:39:02 -0400 To: The development of GNU GRUB Subject: Re: grub mishandles corrupt/missing primary GPT Message-ID: <20131024133902.GS13097@csclub.uwaterloo.ca> References: <9DB3EF6D-6E26-4A9F-BB2D-07CCEF378D7A@colorremedies.com> <52687CC7.4010605@gmail.com> <6400C778-E3A3-42FD-ABF7-E15DF635FC40@colorremedies.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6400C778-E3A3-42FD-ABF7-E15DF635FC40@colorremedies.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 129.97.134.52 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 13:39:19 -0000 On Wed, Oct 23, 2013 at 09:07:21PM -0600, Chris Murphy wrote: > While technically a violation of the UEFI spec, I think this can be worked around by considering the disk GPT if the first entry in the MBR is type 0xEE. I don't know of a hybrid MBR implementation where an entry other than the first is 0xEE. Well everyone other than Microsoft seems to understand how useful support for hybrid setups can be and hence support them. > But if there is no 0xEE entry at all, this is identical to a formerly GPT disk repartitioned as MBR by a utility that doesn't know anything about GPT, and thus doesn't erase the stale GPT data - and therefore must be treated as MBR. That is true. That does not mean there must ONLY be a 0xEE entry. > So perhaps this test is difficult because it's GPT on BIOS, with a limited space BIOS boot partition. However, I think on UEFI computers this should still work with one valid GPT, rather than not boot at all. There's a lot more space for this there. Certainly if using the BIOS boot partition, there really isn't much of a space excuse anymore, unless you run into limitations on how much ram you can use in early boot. > Both primary and backup GPTs are preserved in this case since the primary is in LBA 1 and 2, and only LBA 0 is overwritten with the new MBR. > > UEFI spec says if the MBR signature of 0xaa55 is intact, and there isn't an 0xEE entry, and the partition entries are rational (physically on disk and don't overlap), then the two GPTs are considered stale and the disk is MBR. > > The primary header contains the location of the backup GPT. If the header is sufficiently corrupt, and the backup GPT can't be located, then that's the same as an invalid backup GPT, and in that case fail. > > My point is we shouldn't fail when there is a valid locatable backup GPT. The whole point of having a second GPT is obviated with the current behavior. Sometimes backups are designed in and never used. I don't recall ever seeing any indication Microsoft ever used the second copy of the FAT for anything other than filesystem repair tools. > I don't think we can work around this kind of hardware vendor sabotage. If it looks like a valid GPT, but is actually stale, if it's used and contains incorrect information, then boot fails. Better to try than not try at all. > > It's certainly uncommon. A Google search: corrupt "primary gpt" only turns up 1900 results. But it is possible. > > And this isn't the only mishandling I'm finding, so it's not like GRUB is unique. In fact just now by changing only a single byte in the primary GPT table (I changed the E to an F in the BIOS boot partition type UUID), the kernel suddenly has no idea what disklabel the disk is, and fails to mount rootfs. So I need to track that down too, but it seems like it knows the primary GPT table is corrupt, but then fails to use the backup GPT for some reason. > > An argument against GRUB doing all of this work: maybe the bootloader should be able to blindly trust the primary GPT table with no validity checks? And instead rely on (presently non-existent) checks by the underlying OS to fixi this problem? Something like an fsck_gpt, seeing as nothing else is in a good position to both check and fix such GPTs other than a partition tool. Perhaps. Certainly simpler. I do wonder how Windows handles booting with a corrupt primary GPT. Would you happen to know? (A quick google search didn't find an answer to the question unfortunately). > The UEFI spec says "Software should ask a user for confirmation before restoring the primary GPT" and yet it also requires the unspecified software fix the primary GPT if corrupt. The spec actually uses the word "must". So per usual, the spec has rather lofty demands. So it must fix it after asking the user for confirmation? -- Len Sorensen From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VZPUB-0002le-Hs for mharc-grub-devel@gnu.org; Thu, 24 Oct 2013 14:18:19 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZPU4-0002kS-Hz for grub-devel@gnu.org; Thu, 24 Oct 2013 14:18:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZPTy-0004Z8-2B for grub-devel@gnu.org; Thu, 24 Oct 2013 14:18:12 -0400 Received: from [50.115.112.57] (port=48022 helo=slmp-550-94.slc.westdc.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZPTx-0004Xr-Pk for grub-devel@gnu.org; Thu, 24 Oct 2013 14:18:06 -0400 Received: from c-67-165-243-162.hsd1.co.comcast.net ([67.165.243.162]:56844 helo=[192.168.1.126]) by slmp-550-94.slc.westdc.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VZPTr-003FST-Pi for grub-devel@gnu.org; Thu, 24 Oct 2013 12:18:00 -0600 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: grub mishandles corrupt/missing primary GPT From: Chris Murphy In-Reply-To: <20131024133902.GS13097@csclub.uwaterloo.ca> Date: Thu, 24 Oct 2013 12:17:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <01317010-522C-4C11-9105-0D536426EE36@colorremedies.com> References: <9DB3EF6D-6E26-4A9F-BB2D-07CCEF378D7A@colorremedies.com> <52687CC7.4010605@gmail.com> <6400C778-E3A3-42FD-ABF7-E15DF635FC40@colorremedies.com> <20131024133902.GS13097@csclub.uwaterloo.ca> To: The development of GNU GRUB X-Mailer: Apple Mail (2.1510) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - slmp-550-94.slc.westdc.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - colorremedies.com X-Get-Message-Sender-Via: slmp-550-94.slc.westdc.net: authenticated_id: whatever@colorremedies.com X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 50.115.112.57 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 18:18:18 -0000 On Oct 24, 2013, at 7:39 AM, "Lennart Sorensen" = wrote: > On Wed, Oct 23, 2013 at 09:07:21PM -0600, Chris Murphy wrote: >> While technically a violation of the UEFI spec, I think this can be = worked around by considering the disk GPT if the first entry in the MBR = is type 0xEE. I don't know of a hybrid MBR implementation where an entry = other than the first is 0xEE.=20 >=20 > Well everyone other than Microsoft seems to understand how useful = support > for hybrid setups can be and hence support them. Support is a very strong word. They're basically a craptastic workaround = for prior unfortunate choices. Apple uses them, it hardly supports them. Their tools routinely nuke = hybrid MBRs in favor of PMBRs rendering the secondary OS unbootable; if = the MBR and GPT aren't sync'd, they will bone the correct MBR with wrong = GPT information, rendering the secondary OS unbootable and data = inaccessible. And it does this silently. I think it's OK to tiptoe around hybrid MBRs, and do something sensible, = if possible. Supporting them is out of scope because there's no standard = or agreed upon way to interpret them. >=20 >> But if there is no 0xEE entry at all, this is identical to a formerly = GPT disk repartitioned as MBR by a utility that doesn't know anything = about GPT, and thus doesn't erase the stale GPT data - and therefore = must be treated as MBR. >=20 > That is true. That does not mean there must ONLY be a 0xEE entry. Well, there must be only an 0xEE entry to treat the disk as a pure GPT = disk. Once there's 0xEE and 1-3 additional entries, it's a hybrid logic, very = few combinations of which are sane. When the MBR and GPT don't agree = with each other, which on Macs is actually somewhat common once you've = used Bootcamp Assistant, because users think it's OK to resize OS X = volumes in OS X Disk Utility, and then use free space to either create = an additional OS X partition, or grow an existing Windows partition from = within Windows. Oops, now the MBR and GPT don't agree with each other, = so which one is correct? Well, it's ambiguous. With a few exceptions, there's actually no way to know what's correct, = which is why hybrid MBRs are ultimately shit. But again, I'm fine = dodging piles of crap rather than cleaning up other people's messes. >=20 > I do wonder how Windows handles booting with a corrupt primary GPT. > Would you happen to know? (A quick google search didn't find an answer > to the question unfortunately). I haven't tested it because I don't have a UEFI machine here, only Apple = EFI. So I'm stuck with CSM-BIOS mode booting of Windows, which means it = will only use MBR. I haven't figured out UEFI within qemu/kvm, and if = that can boot Windows in UEFI mode. >=20 >> The UEFI spec says "Software should ask a user for confirmation = before restoring the primary GPT" and yet it also requires the = unspecified software fix the primary GPT if corrupt. The spec actually = uses the word "must". So per usual, the spec has rather lofty demands. >=20 > So it must fix it after asking the user for confirmation? Yes it's just being silly. But the take away is that (partitioning) = tools are behaving wrongly if they understand GPT, yet ignore or can't = fix problems with either GPT. The spec only says software, it doesn't = specify what software, so I'm assuming partitioning tools. Obviously the = kernel is software, but it's not in a position to ask the user anything. Chris Murphy= From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Vcjo5-0004Hm-UY for mharc-grub-devel@gnu.org; Sat, 02 Nov 2013 18:36:37 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47591) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vcjnv-0004Gg-6k for grub-devel@gnu.org; Sat, 02 Nov 2013 18:36:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vcjnm-00064h-Ob for grub-devel@gnu.org; Sat, 02 Nov 2013 18:36:27 -0400 Received: from mail-ee0-x232.google.com ([2a00:1450:4013:c00::232]:53983) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vcjnm-00063q-Hn for grub-devel@gnu.org; Sat, 02 Nov 2013 18:36:18 -0400 Received: by mail-ee0-f50.google.com with SMTP id l10so408851eei.37 for ; Sat, 02 Nov 2013 15:36:17 -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=A+a+QsHw+IkoX1ZE3u4nqyYijd1OfWRC5fox1Dk8TlY=; b=Ai+LuoXDugNgAiwEvQ4O9IfnfKCmDllSo6wX/j5wX8e//kz8m81EJWQKhr2DT8aB+T AZNh7fne8pLp9GnWomJm0m6nVdQltuxRfiddBtr51mc2ScKQTztT7LMgn/A3yWt7vT2l t+f+Mumrsw1lN8/JT7Iudpi0paIKeGl3ARwHX1eMAcfVxC2CISKIs4ZYhZI6QWp7Thea vPQV900xsWvJC495m9DLaPrct7sPR9DJuRnh0PhaFHrmsjYXDowxBHOewykkavnIP6Dk s54tCGagHQ6LsUvBQ2GeDyMHyjR+sRuzhmwpmendb43S8BG0+jmTUvp4bpDS5CnU8G7c v5Kg== X-Received: by 10.14.193.198 with SMTP id k46mr128866een.128.1383431776963; Sat, 02 Nov 2013 15:36:16 -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 bn13sm25796974eeb.11.2013.11.02.15.36.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Nov 2013 15:36:15 -0700 (PDT) Message-ID: <52757E5E.6020505@gmail.com> Date: Sat, 02 Nov 2013 23:36:14 +0100 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> <52687CC7.4010605@gmail.com> <6400C778-E3A3-42FD-ABF7-E15DF635FC40@colorremedies.com> <20131024133902.GS13097@csclub.uwaterloo.ca> <01317010-522C-4C11-9105-0D536426EE36@colorremedies.com> In-Reply-To: <01317010-522C-4C11-9105-0D536426EE36@colorremedies.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2UETDLOGJHEHBHDKXEQJP" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::232 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: Sat, 02 Nov 2013 22:36:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2UETDLOGJHEHBHDKXEQJP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 24.10.2013 20:17, Chris Murphy wrote: > Yes it's just being silly. But the take away is that (partitioning) too= ls are behaving wrongly if they understand GPT, yet ignore or can't fix p= roblems with either GPT. The spec only says software, it doesn't specify = what software, so I'm assuming partitioning tools. Obviously the kernel i= s software, but it's not in a position to ask the user anything. GRUB logic is that it should be able to read corrupted as far as it's not too corrupted and let kernel/partitioning tool to do the permanent fi= x. ------enig2UETDLOGJHEHBHDKXEQJP 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/ iF4EAREKAAYFAlJ1fl4ACgkQNak7dOguQgl5ogD/cyefobmwCLmhhPGhnrxlC9mk Iuw7ThVec1kQfvofOfcA/2kK9W/15LEgUx2RoV4f5e75e4ZR56d5zp8QW8SaPYDC =NWCj -----END PGP SIGNATURE----- ------enig2UETDLOGJHEHBHDKXEQJP-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Vq2lN-0003tO-Fk for mharc-grub-devel@gnu.org; Mon, 09 Dec 2013 10:28:49 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq2lF-0003sy-1r for grub-devel@gnu.org; Mon, 09 Dec 2013 10:28:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vq2l9-0003tr-2X for grub-devel@gnu.org; Mon, 09 Dec 2013 10:28:40 -0500 Received: from cdptpa-omtalb.mail.rr.com ([75.180.132.120]:48941) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq2l8-0003tm-UW for grub-devel@gnu.org; Mon, 09 Dec 2013 10:28:34 -0500 X-Authority-Analysis: v=2.0 cv=H69ZMpki c=1 sm=0 a=/DbS/tiKggfTkRRHPZEB4g==:17 a=h_Sp9wbh10QA:10 a=Sf1lQz6BAFEA:10 a=S1A5HrydsesA:10 a=Qsx_du5GiBkA:10 a=IkcTkHD0fZMA:10 a=fxJcL_dCAAAA:8 a=KGjhK52YXX0A:10 a=tQUrN4PDdR4A:10 a=QfKxxUxMAAAA:8 a=wAb8YmKwIgLFZilddDcA:9 a=QEXdDO2ut3YA:10 a=/DbS/tiKggfTkRRHPZEB4g==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 67.78.168.186 Received: from [67.78.168.186] ([67.78.168.186:64066] helo=[10.1.1.236]) by cdptpa-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id CD/6A-11872-1A1E5A25; Mon, 09 Dec 2013 15:28:34 +0000 Message-ID: <52A5E1A1.3000103@ubuntu.com> Date: Mon, 09 Dec 2013 10:28:33 -0500 From: Phillip Susi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: grub mishandles corrupt/missing primary GPT References: <9DB3EF6D-6E26-4A9F-BB2D-07CCEF378D7A@colorremedies.com> <52687CC7.4010605@gmail.com> In-Reply-To: <52687CC7.4010605@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 75.180.132.120 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: Mon, 09 Dec 2013 15:28:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/23/2013 9:49 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > partmap module is size-critical and CRC32 verification is pretty > big. There are 3 problems with backup header: The grub core no longer fits in 63 sectors in all but the most trivial configurations as it is, and a 2048 sector embed area has been standard now for several years, so I don't think size is a problem. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSpeGhAAoJEI5FoCIzSKrw8XYH/09Aou9FwkH4i2bhVqYeKNeb ge0VYz3JNSxVpEVz3cmw0STNyz4/5vF+lJ59Renjbo7vj8BhVcYpMF2FfuUtdM2f 8vgqAMWnCRud7dJgO13G1CopNfAg/rjduc2zFmxMDYdFtyGEGaFYUhrIXSjetzj2 g2Lryoah6BPIdvQA/kANSNvixTj/b2+uxUpnKSbqR2b+5c8zcdXkhUJGJwR9ZEmh 4K10uMA4QlR+Y2QNqxwSPzWo44NY5xmupjOVnNFeV/ROC/OAXQXoOa8lrapDLWta vTSH6eddfoBdMqT5hdfQYnSgn61/sca1DR4IB9LdAVW+tPq4znDB6paFRfx+38A= =YXGu -----END PGP SIGNATURE----- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Vq3AO-0007Uk-Cr for mharc-grub-devel@gnu.org; Mon, 09 Dec 2013 10:54:40 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq3AC-00079f-JS for grub-devel@gnu.org; Mon, 09 Dec 2013 10:54:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vq3A1-0003CR-ES for grub-devel@gnu.org; Mon, 09 Dec 2013 10:54:28 -0500 Received: from mail-wg0-x231.google.com ([2a00:1450:400c:c00::231]:51696) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq3A1-0003CL-7o for grub-devel@gnu.org; Mon, 09 Dec 2013 10:54:17 -0500 Received: by mail-wg0-f49.google.com with SMTP id x12so3553650wgg.4 for ; Mon, 09 Dec 2013 07:54:16 -0800 (PST) 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=MSz4F4LY2Z9xS5/fyRqZW72dr7pIezGN1MquWsHpIrk=; b=pdX9bVrOhUFoRSjKN6IB4Ss8fbWFEUr2UkFFO/A/+/q9OFPw77g1pBpFxjBHffeqzK Llqzamht3GylzGOMwsvMRkBMPlDXzZODS7iAK1jwT1ElmADRmkNl8spPMFT5uxpXnKQ0 F1BaMkMHirNGzzdKQBHzg5BRvBpsd2MQvurEbmixtjM4UNh3VEliRna044uN6BIw+5mO Eor51/nOeyJor+b9onfKPrZbntQXT2evOfEs3c0lZDZ9u8LScGFc9QgNVWLf+ZFSSjQZ Cxamk9h5Fzc7/WfUwXYO11kRsfl2d6SxyPkSx7WxeCDmArZXRyD4DYvechK5bwcA7AF2 2Kvw== X-Received: by 10.180.37.112 with SMTP id x16mr14966336wij.48.1386604456270; Mon, 09 Dec 2013 07:54:16 -0800 (PST) Received: from [192.168.1.16] (85-188.196-178.cust.bluewin.ch. [178.196.188.85]) by mx.google.com with ESMTPSA id cx3sm24727415wib.0.2013.12.09.07.54.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 07:54:13 -0800 (PST) Message-ID: <52A5E7A2.6060104@gmail.com> Date: Mon, 09 Dec 2013 16:54:10 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: grub mishandles corrupt/missing primary GPT References: <9DB3EF6D-6E26-4A9F-BB2D-07CCEF378D7A@colorremedies.com> <52687CC7.4010605@gmail.com> <52A5E1A1.3000103@ubuntu.com> In-Reply-To: <52A5E1A1.3000103@ubuntu.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aBTUWtEag36PLu95Swamow97GISKsHVhO" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::231 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: Mon, 09 Dec 2013 15:54:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aBTUWtEag36PLu95Swamow97GISKsHVhO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09.12.2013 16:28, Phillip Susi wrote: > On 10/23/2013 9:49 PM, Vladimir '=CF=86-coder/phcoder' Serbinenko wrote= : >> partmap module is size-critical and CRC32 verification is pretty >> big. There are 3 problems with backup header: >=20 > The grub core no longer fits in 63 sectors in all but the most trivial > configurations as it is, Not true. I've checked: all configs not involving compressed fs or diskfilter fit in 31K. > and a 2048 sector embed area has been > standard now for several years, so I don't think size is a problem. >=20 We're speaking abut GPT, nothing to do with MBR embed area. My problem with that is that it increases complexity a lot in currently simple code. And also I had experience with backup header out of place due to disk reconfiguration and primary header corrupted but still well enough to have valid partitions. I could boot this system by using "gpt" linux option. With proposed changes this system would become unbootable. --aBTUWtEag36PLu95Swamow97GISKsHVhO 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/ iF4EAREKAAYFAlKl56IACgkQmBXlbbo5nOsSHgD+PjX+nKrEdyQ5Ph/FVWdZTnUP hpGxCC/ZYNl6nbo2pU0A/3iImlVZgMqqB+PRDIK72F3OCMhDwHVlWZLo6C35mXDx =E65P -----END PGP SIGNATURE----- --aBTUWtEag36PLu95Swamow97GISKsHVhO-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VqAva-0006in-V2 for mharc-grub-devel@gnu.org; Mon, 09 Dec 2013 19:11:54 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53138) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqAvR-0006iA-5S for grub-devel@gnu.org; Mon, 09 Dec 2013 19:11:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VqAvJ-0005lw-RH for grub-devel@gnu.org; Mon, 09 Dec 2013 19:11:45 -0500 Received: from [50.115.112.57] (port=11419 helo=slmp-550-94.slc.westdc.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqAvJ-0005kE-HD for grub-devel@gnu.org; Mon, 09 Dec 2013 19:11:37 -0500 Received: from c-50-183-15-223.hsd1.co.comcast.net ([50.183.15.223]:62825 helo=[192.168.1.145]) by slmp-550-94.slc.westdc.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1VqAvF-003Qdp-23 for grub-devel@gnu.org; Mon, 09 Dec 2013 17:11:33 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: grub mishandles corrupt/missing primary GPT From: Chris Murphy In-Reply-To: <52A5E7A2.6060104@gmail.com> Date: Mon, 9 Dec 2013 17:11:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <50736662-98F2-4F6B-AC7F-E93885391F26@colorremedies.com> References: <9DB3EF6D-6E26-4A9F-BB2D-07CCEF378D7A@colorremedies.com> <52687CC7.4010605@gmail.com> <52A5E1A1.3000103@ubuntu.com> <52A5E7A2.6060104@gmail.com> To: The development of GNU GRUB X-Mailer: Apple Mail (2.1510) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - slmp-550-94.slc.westdc.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - colorremedies.com X-Get-Message-Sender-Via: slmp-550-94.slc.westdc.net: authenticated_id: whatever@colorremedies.com X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 50.115.112.57 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: Tue, 10 Dec 2013 00:11:53 -0000 On Dec 9, 2013, at 8:54 AM, Vladimir '=CF=86-coder/phcoder' Serbinenko = wrote: > On 09.12.2013 16:28, Phillip Susi wrote: >> On 10/23/2013 9:49 PM, Vladimir '=CF=86-coder/phcoder' Serbinenko = wrote: >>> partmap module is size-critical and CRC32 verification is pretty >>> big. There are 3 problems with backup header: >>=20 >> The grub core no longer fits in 63 sectors in all but the most = trivial >> configurations as it is, > Not true. I've checked: all configs not involving compressed fs or > diskfilter fit in 31K. >> and a 2048 sector embed area has been >> standard now for several years, so I don't think size is a problem. >>=20 > We're speaking abut GPT, nothing to do with MBR embed area. >=20 > My problem with that is that it increases complexity a lot in = currently > simple code. > And also I had experience with backup header out of place due to disk > reconfiguration and primary header corrupted but still well enough to > have valid partitions. I could boot this system by using "gpt" linux > option. With proposed changes this system would become unbootable. Technically if the alternate is invalid by being in the wrong location = (either end of disk or where the primary header says it should be = located), and the header is also invalid because the header is corrupt, = then the disk has an invalid GPT. So long as GRUB knows a valid MBR = without an 0xEE entry means any found GPT is stale (or rather, simply = doesn't go looking for the GPT), it seems possibly reasonable for GRUB = to blindly use the primary partition table. If it fails, it fails, even = if it's unfortunate there's no fallback to a valid alternate GPT. Maybe someone could argue it's a security problem for an invalid GPT = being used despite being invalid? Also, I have some evidence that newer Apple EFI firmware are repairing = these cases. I have one older computer that I can consistently corrupt, = and it remains corrupted through boot, even to the degree the (linux) = kernel face plants by default if the primary header or table is corrupt, = unless the gpt kernel parameter is used. Yet a newer computer boots = without the kernel complaining, and upon startup completion the GPT is = fixed. Identically performed installations were performed in those = cases. So maybe it can be argued the firmware has a role to play in fixing up = GPT? Or maybe this is a hideously bad idea for firmware, which as we = know is slightly less than massively bug ridden, to have such write = privileges to the disk. Chris Murphy= From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VqBbs-0001jB-My for mharc-grub-devel@gnu.org; Mon, 09 Dec 2013 19:55:36 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39781) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqBbl-0001iu-9y for grub-devel@gnu.org; Mon, 09 Dec 2013 19:55:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VqBbf-00051z-Si for grub-devel@gnu.org; Mon, 09 Dec 2013 19:55:29 -0500 Received: from mail-ea0-x22f.google.com ([2a00:1450:4013:c01::22f]:51349) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqBbf-00051u-IB for grub-devel@gnu.org; Mon, 09 Dec 2013 19:55:23 -0500 Received: by mail-ea0-f175.google.com with SMTP id z10so1911576ead.34 for ; Mon, 09 Dec 2013 16:55:22 -0800 (PST) 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=Gt+s8T4h5AdHJZ4h8vEunbsCGiMFwNXtFUkDHeqQzl4=; b=j24e+d1Ogi7hYAlF1O3BVbf4WR5PyTax2u+yOGJRpK/fL1HL/adp+fYDXrTpKkUEY7 iTmWUyJXCZdSt7kyR482cGj68mgGcr/nWFQp6E5BD4kSP0E0t7QAJdtCZF7IFm16jKT2 KC/ZARlCFi/WexdPmaxD8T09hZScLS+aylk9srsBSd7OuHAdL7m9yAZ7ZJOCNA/xjdId fn/daUVmHFmNwOCMVugmR+vYvdvBdtbiFpGGIQ4pGbH0DfcjxnpU0v4mLNjqKzFpQP1n hYbC2mt6DXraqBTPoBAufu5s08yvPLyMMmSRf1drF1SutoW/wYtWa7MPeRbRI7rSAjyL 0bIg== X-Received: by 10.15.82.136 with SMTP id a8mr8728885eez.81.1386636922525; Mon, 09 Dec 2013 16:55:22 -0800 (PST) Received: from [192.168.1.16] (85-188.196-178.cust.bluewin.ch. [178.196.188.85]) by mx.google.com with ESMTPSA id 4sm5020349eed.14.2013.12.09.16.55.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 16:55:21 -0800 (PST) Message-ID: <52A66678.4040900@gmail.com> Date: Tue, 10 Dec 2013 01:55:20 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: grub mishandles corrupt/missing primary GPT References: <9DB3EF6D-6E26-4A9F-BB2D-07CCEF378D7A@colorremedies.com> <52687CC7.4010605@gmail.com> <52A5E1A1.3000103@ubuntu.com> <52A5E7A2.6060104@gmail.com> <50736662-98F2-4F6B-AC7F-E93885391F26@colorremedies.com> In-Reply-To: <50736662-98F2-4F6B-AC7F-E93885391F26@colorremedies.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EEnfgx4GGTMnb3aPgMSBoTbonmFtXQdtW" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::22f 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: Tue, 10 Dec 2013 00:55:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EEnfgx4GGTMnb3aPgMSBoTbonmFtXQdtW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10.12.2013 01:11, Chris Murphy wrote: >=20 > On Dec 9, 2013, at 8:54 AM, Vladimir '=CF=86-coder/phcoder' Serbinenko = wrote: >=20 >> On 09.12.2013 16:28, Phillip Susi wrote: >>> On 10/23/2013 9:49 PM, Vladimir '=CF=86-coder/phcoder' Serbinenko wro= te: >>>> partmap module is size-critical and CRC32 verification is pretty >>>> big. There are 3 problems with backup header: >>> >>> The grub core no longer fits in 63 sectors in all but the most trivia= l >>> configurations as it is, >> Not true. I've checked: all configs not involving compressed fs or >> diskfilter fit in 31K. >>> and a 2048 sector embed area has been >>> standard now for several years, so I don't think size is a problem. >>> >> We're speaking abut GPT, nothing to do with MBR embed area. >> >> My problem with that is that it increases complexity a lot in currentl= y >> simple code. >> And also I had experience with backup header out of place due to disk >> reconfiguration and primary header corrupted but still well enough to >> have valid partitions. I could boot this system by using "gpt" linux >> option. With proposed changes this system would become unbootable. >=20 > Technically if the alternate is invalid by being in the wrong location = (either end of disk or where the primary header says it should be located= ), and the header is also invalid because the header is corrupt, then the= disk has an invalid GPT. So long as GRUB knows a valid MBR without an 0x= EE entry means any found GPT is stale (or rather, simply doesn't go looki= ng for the GPT), it seems possibly reasonable for GRUB to blindly use the= primary partition table. If it fails, it fails, even if it's unfortunate= there's no fallback to a valid alternate GPT. It's already the case. Probably the real remaining points are: - Should we use backup headers under some conditions? - Should msdos partitions be visible? Always? When it's not a PMBR? Or when GPT is corrupt? >=20 > Maybe someone could argue it's a security problem for an invalid GPT be= ing used despite being invalid? >=20 CRC32 isn't a MAC. Anyone who can modify GPT can fix CRC32 as well. > Also, I have some evidence that newer Apple EFI firmware are repairing = these cases. I have one older computer that I can consistently corrupt, a= nd it remains corrupted through boot, even to the degree the (linux) kern= el face plants by default if the primary header or table is corrupt, unle= ss the gpt kernel parameter is used. Yet a newer computer boots without t= he kernel complaining, and upon startup completion the GPT is fixed. Iden= tically performed installations were performed in those cases. >=20 > So maybe it can be argued the firmware has a role to play in fixing up = GPT? Or maybe this is a hideously bad idea for firmware, which as we know= is slightly less than massively bug ridden, to have such write privilege= s to the disk. >=20 Firmware writing to disk without being explicitly asked for it is a bugware or spyware. >=20 > Chris Murphy > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >=20 --EEnfgx4GGTMnb3aPgMSBoTbonmFtXQdtW 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/ iF4EAREKAAYFAlKmZngACgkQmBXlbbo5nOvNrwD/beOxrGX0W/jSvCjwqtKu7Stp 6PsaqMDjnO2lLMFZE0sBAKuIuh25zMzkTFm5FKJp5GVGnI8uFr0wIxjabqBczggR =DM+r -----END PGP SIGNATURE----- --EEnfgx4GGTMnb3aPgMSBoTbonmFtXQdtW-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VqCZ3-0002H5-Vd for mharc-grub-devel@gnu.org; Mon, 09 Dec 2013 20:56:45 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60309) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqCYv-0002Gi-Bw for grub-devel@gnu.org; Mon, 09 Dec 2013 20:56:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VqCYo-0001nC-0Z for grub-devel@gnu.org; Mon, 09 Dec 2013 20:56:37 -0500 Received: from [50.115.112.57] (port=38671 helo=slmp-550-94.slc.westdc.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqCYn-0001lg-NX for grub-devel@gnu.org; Mon, 09 Dec 2013 20:56:29 -0500 Received: from c-50-183-15-223.hsd1.co.comcast.net ([50.183.15.223]:63092 helo=[192.168.1.145]) by slmp-550-94.slc.westdc.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1VqCYj-003ytM-V3 for grub-devel@gnu.org; Mon, 09 Dec 2013 18:56:26 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: grub mishandles corrupt/missing primary GPT From: Chris Murphy In-Reply-To: <52A66678.4040900@gmail.com> Date: Mon, 9 Dec 2013 18:56:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9DB3EF6D-6E26-4A9F-BB2D-07CCEF378D7A@colorremedies.com> <52687CC7.4010605@gmail.com> <52A5E1A1.3000103@ubuntu.com> <52A5E7A2.6060104@gmail.com> <50736662-98F2-4F6B-AC7F-E93885391F26@colorremedies.com> <52A66678.4040900@gmail.com> To: The development of GNU GRUB X-Mailer: Apple Mail (2.1510) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - slmp-550-94.slc.westdc.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - colorremedies.com X-Get-Message-Sender-Via: slmp-550-94.slc.westdc.net: authenticated_id: whatever@colorremedies.com X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 50.115.112.57 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: Tue, 10 Dec 2013 01:56:44 -0000 On Dec 9, 2013, at 5:55 PM, Vladimir '=CF=86-coder/phcoder' Serbinenko = wrote: > On 10.12.2013 01:11, Chris Murphy wrote: >>=20 >> Technically if the alternate is invalid by being in the wrong = location (either end of disk or where the primary header says it should = be located), and the header is also invalid because the header is = corrupt, then the disk has an invalid GPT. So long as GRUB knows a valid = MBR without an 0xEE entry means any found GPT is stale (or rather, = simply doesn't go looking for the GPT), it seems possibly reasonable for = GRUB to blindly use the primary partition table. If it fails, it fails, = even if it's unfortunate there's no fallback to a valid alternate GPT. > It's already the case. > Probably the real remaining points are: > - Should we use backup headers under some conditions? It would be nice. But if not by validating at least the table checksum, = how? I don't know how big the CRC32 code is in comparison to code needed = to evaluate the table some with some heuristic approach. Also it seems = like a bit flip of the most important partition data, the needed = partition's start sector value (is the end value needed?) is a really = rare case. The more likely scenario is some software alters the GPT and = has a bad write or crash at that moment, in which case the cause of boot = failure isn't a complete mystery. > - Should msdos partitions be visible? Always? When it's not a PMBR? Or > when GPT is corrupt? I suggest parsing LBA 0 first for a conventional MBR, if it is, don't = even parse LBA1 looking for a GPT. If the MBR is either hybrid or PMBR, = then parse the GPT. I don't think it's a good idea to get into a case = where GRUB looks at both MBR and GPT and has to figure out which = partitions to honor or ignore if they aren't in sync. Even in the = constrained Apple OS X Boot Camp implementation there has been a lot of = data loss due to missteps in interpreting hybrid MBRs. >> So maybe it can be argued the firmware has a role to play in fixing = up GPT? Or maybe this is a hideously bad idea for firmware, which as we = know is slightly less than massively bug ridden, to have such write = privileges to the disk. >>=20 > Firmware writing to disk without being explicitly asked for it is a > bugware or spyware. Yes I definitely find this really interesting behavior. If the firmware = does have the ability to write, I wonder if an arbitrary EFI application = could have write permission? If so, it seems like a potentially huge = attack vector. I don't see what else could be repairing the GPT: = computer firmware, SSD firmware, GRUB, linux kernel. I think GRUB and = linux are out, otherwise one of them would have fixed the GPT on other = hardware that used an identical installation source. Chris Murphy= From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VqCiP-0006We-IW for mharc-grub-devel@gnu.org; Mon, 09 Dec 2013 21:06:25 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35902) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqCiI-0006Sd-2y for grub-devel@gnu.org; Mon, 09 Dec 2013 21:06:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VqCiC-0006US-Lm for grub-devel@gnu.org; Mon, 09 Dec 2013 21:06:18 -0500 Received: from mail-ea0-x22d.google.com ([2a00:1450:4013:c01::22d]:57194) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqCiC-0006To-Ap for grub-devel@gnu.org; Mon, 09 Dec 2013 21:06:12 -0500 Received: by mail-ea0-f173.google.com with SMTP id o10so1895184eaj.18 for ; Mon, 09 Dec 2013 18:06:11 -0800 (PST) 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=K/Amth+hyApoCqNjCg8lWMaPknhQ8Aiq4yDGyEZe+OQ=; b=fpjXWoP9QUWDQ+RPy+Dnw6PbZFcOkrBI00kY70sgH77Pr7StP8hOzz0bsjBT9IKmbc Jmczduyn3Y2VttLEyeSV0lhpJReKi5HgkgKWxVL/LtKhFJxsbnBuw9duDKL7/v9nIOGv OInoRUJwTWOjSX/roTJO7gkYm+R1Guht2YPA6+YIwD3BakrnG5taYzKS9x/B4Rds83k8 wrl2ZD9TnsZaVI6SlaJk1gO7Frytgri6vjJ4FQhdPrvoO/QHFjGpJEeZK4p91ITBso2m MEsJ7z7K98Q+IYG0InrpR2Uw1I3ZP3xDXQ9Z2Z0gcZ+1STKo7hnB4LY+mM99oBpjpJAh OOwQ== X-Received: by 10.14.173.7 with SMTP id u7mr15050857eel.24.1386641171565; Mon, 09 Dec 2013 18:06:11 -0800 (PST) Received: from [192.168.1.16] (85-188.196-178.cust.bluewin.ch. [178.196.188.85]) by mx.google.com with ESMTPSA id a51sm35355254eeh.8.2013.12.09.18.06.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 18:06:10 -0800 (PST) Message-ID: <52A67712.20608@gmail.com> Date: Tue, 10 Dec 2013 03:06:10 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: grub mishandles corrupt/missing primary GPT References: <9DB3EF6D-6E26-4A9F-BB2D-07CCEF378D7A@colorremedies.com> <52687CC7.4010605@gmail.com> <52A5E1A1.3000103@ubuntu.com> <52A5E7A2.6060104@gmail.com> <50736662-98F2-4F6B-AC7F-E93885391F26@colorremedies.com> <52A66678.4040900@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dabWGj2LRAAoHbJerQLeV5grGdaAxTpJB" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::22d 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: Tue, 10 Dec 2013 02:06:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dabWGj2LRAAoHbJerQLeV5grGdaAxTpJB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10.12.2013 02:56, Chris Murphy wrote: >=20 > On Dec 9, 2013, at 5:55 PM, Vladimir '=CF=86-coder/phcoder' Serbinenko = wrote: >=20 >> On 10.12.2013 01:11, Chris Murphy wrote: >>> >>> Technically if the alternate is invalid by being in the wrong locatio= n (either end of disk or where the primary header says it should be locat= ed), and the header is also invalid because the header is corrupt, then t= he disk has an invalid GPT. So long as GRUB knows a valid MBR without an = 0xEE entry means any found GPT is stale (or rather, simply doesn't go loo= king for the GPT), it seems possibly reasonable for GRUB to blindly use t= he primary partition table. If it fails, it fails, even if it's unfortuna= te there's no fallback to a valid alternate GPT. >> It's already the case. >> Probably the real remaining points are: >> - Should we use backup headers under some conditions? >=20 > It would be nice. But if not by validating at least the table checksum,= how? I don't know how big the CRC32 code is in comparison to code needed= to evaluate the table some with some heuristic approach. Also it seems l= ike a bit flip of the most important partition data, the needed partition= 's start sector value (is the end value needed?) is a really rare case. T= he more likely scenario is some software alters the GPT and has a bad wri= te or crash at that moment, in which case the cause of boot failure isn't= a complete mystery. >=20 We need end value as well. Here the interesting part is that the data you need is about 1% of checksummed area, so in most cases checksum check gets more in the way than it helps. >> - Should msdos partitions be visible? Always? When it's not a PMBR? Or= >> when GPT is corrupt? >=20 > I suggest parsing LBA 0 first for a conventional MBR, if it is, don't e= ven parse LBA1 looking for a GPT. If the MBR is either hybrid or PMBR, th= en parse the GPT. I don't think it's a good idea to get into a case where= GRUB looks at both MBR and GPT and has to figure out which partitions to= honor or ignore if they aren't in sync. Even in the constrained Apple OS= X Boot Camp implementation there has been a lot of data loss due to miss= teps in interpreting hybrid MBRs. >=20 GRUB has handling of multiple partmap scenarios but it won't handle all the cases of desync correctly. E.g. partitions with same start but different end would be recognized as same UUID with most filesystems but the files may be unreadable in case of premature partition end. >=20 >>> So maybe it can be argued the firmware has a role to play in fixing u= p GPT? Or maybe this is a hideously bad idea for firmware, which as we kn= ow is slightly less than massively bug ridden, to have such write privile= ges to the disk. >>> >> Firmware writing to disk without being explicitly asked for it is a >> bugware or spyware. >=20 >=20 > Yes I definitely find this really interesting behavior. If the firmware= does have the ability to write, I wonder if an arbitrary EFI application= could have write permission? If so, it seems like a potentially huge att= ack vector. I don't see what else could be repairing the GPT: computer fi= rmware, SSD firmware, GRUB, linux kernel. I think GRUB and linux are out,= otherwise one of them would have fixed the GPT on other hardware that us= ed an identical installation source. >=20 Firmware has full write capability. BIOS, EFI, IEEE1275, ARC(S) all have disk write functions usable by bootloader U-Boot has only read functions. Remaining GRUB platforms have no disk functions and GRUB uses own drivers= =2E >=20 > Chris Murphy > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >=20 --dabWGj2LRAAoHbJerQLeV5grGdaAxTpJB 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/ iF4EAREKAAYFAlKmdxIACgkQmBXlbbo5nOuddwEAgGchxBhFq8wX9matizkQtbGx 3cptzXyn8CUmP5nx+aoA/3KEIF0/3KuBZwdmLvz2pLOaW3qLMrklJQfI2WW9f1/n =52k8 -----END PGP SIGNATURE----- --dabWGj2LRAAoHbJerQLeV5grGdaAxTpJB-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VqT8U-0001d5-Va for mharc-grub-devel@gnu.org; Tue, 10 Dec 2013 14:38:27 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqT8N-0001TE-CR for grub-devel@gnu.org; Tue, 10 Dec 2013 14:38:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VqT8H-0006f0-DI for grub-devel@gnu.org; Tue, 10 Dec 2013 14:38:19 -0500 Received: from cdptpa-omtalb.mail.rr.com ([75.180.132.120]:47721) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqT8H-0006eo-8O for grub-devel@gnu.org; Tue, 10 Dec 2013 14:38:13 -0500 X-Authority-Analysis: v=2.0 cv=dq5Z+ic4 c=1 sm=0 a=/DbS/tiKggfTkRRHPZEB4g==:17 a=h_Sp9wbh10QA:10 a=Sf1lQz6BAFEA:10 a=S1A5HrydsesA:10 a=Qsx_du5GiBkA:10 a=8nJEP1OIZ-IA:10 a=fxJcL_dCAAAA:8 a=KGjhK52YXX0A:10 a=tQUrN4PDdR4A:10 a=QfKxxUxMAAAA:8 a=40M9Jh3qkufbH6vqYp8A:9 a=wPNLvfGTeEIA:10 a=PoXAWLYL1hQA:10 a=/DbS/tiKggfTkRRHPZEB4g==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 67.78.168.186 Received: from [67.78.168.186] ([67.78.168.186:50340] helo=[10.1.1.236]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id AD/C0-21884-4AD67A25; Tue, 10 Dec 2013 19:38:12 +0000 Message-ID: <52A76DA3.1010807@ubuntu.com> Date: Tue, 10 Dec 2013 14:38:11 -0500 From: Phillip Susi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: grub mishandles corrupt/missing primary GPT References: <9DB3EF6D-6E26-4A9F-BB2D-07CCEF378D7A@colorremedies.com> <52687CC7.4010605@gmail.com> <52A5E1A1.3000103@ubuntu.com> <52A5E7A2.6060104@gmail.com> In-Reply-To: <52A5E7A2.6060104@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 75.180.132.120 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: Tue, 10 Dec 2013 19:38:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/9/2013 10:54 AM, Vladimir '?-coder/phcoder' Serbinenko wrote: > Not true. I've checked: all configs not involving compressed fs or > diskfilter fit in 31K. As I said, "trivial" configurations ;) ext2 with no raid or lvm fits... btrfs or any combination of raid or lvm doesn't. > We're speaking abut GPT, nothing to do with MBR embed area. You seemed to be concerned that increasing the size to deal with GPT properly would be bad for MBR setups. MBR setups already have plenty of spare room in the vast majority of cases. > My problem with that is that it increases complexity a lot in > currently simple code. And also I had experience with backup header > out of place due to disk reconfiguration and primary header > corrupted but still well enough to have valid partitions. I could > boot this system by using "gpt" linux option. With proposed changes > this system would become unbootable. One very damaged configuration becomes unbootable, many other less damaged configurations become bootable. Good trade in my book. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSp22jAAoJEI5FoCIzSKrwxcEH/1Ban2YrF5XKC0qmywYnUjDc Bk29a/1KQTPEgX8L8gm9k6cmdIWis+bPCn2HLxNo738/9OmAlUK23Tt5mXgAfy3j 6H+wZPl/NunNrYiWrVjql+sBgKyC69k6tGUwEXUeldyQRBfMWagJtbJGlZC7jmcq zPwjME+hys+JDXSIhSDLWT6+EpNpwha8e147vlDKJ9CFA83l8WVR1kB6RuIloUly iAPHavx33unqPc2vLghsajIj7MhGTzTKy0jDs1g8u1wZW3A2oJKMWAuz/FiCu1fL K1wHeR0Mi6QeEKeQkbaNotAgW6CXlWO6zLzhdF7SuQRBsTxLAp6/ymrthGUQECA= =tJLy -----END PGP SIGNATURE-----