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--