[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: grub mishandles corrupt/missing primary GPT

From: Chris Murphy
Subject: Re: grub mishandles corrupt/missing primary GPT
Date: Mon, 9 Dec 2013 18:56:24 -0700

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]