Re: grub mishandles corrupt/missing primary GPT

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 10.12.2013 02:56, Chris Murphy wrote:
> 
> On Dec 9, 2013, at 5:55 PM, Vladimir 'φ-coder/phcoder' Serbinenko 
> <address@hidden> 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.
> 
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?
> 
> 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.
> 
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.
> 
>>> 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.
> 
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.

> 
> Chris Murphy
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

signature.asc
Description: OpenPGP digital signature