Re: grub mishandles corrupt/missing primary GPT

[Chris Murphy]

On Dec 9, 2013, at 8:54 AM, Vladimir 'φ-coder/phcoder' Serbinenko 
<address@hidden> wrote:

> On 09.12.2013 16:28, Phillip Susi wrote:
>> 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,
> 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 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