On Dec 9, 2013, at 5:55 PM, Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com> wrote:
> On 10.12.2013 01:11, Chris Murphy wrote: >> >> 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. >> > 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
