Re: grub mishandles corrupt/missing primary GPT

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 10.12.2013 01:11, Chris Murphy wrote:
> 
> 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.
It's already the case.
Probably the real remaining points are:
- Should we use backup headers under some conditions?
- Should msdos partitions be visible? Always? When it's not a PMBR? Or
when GPT is corrupt?
> 
> Maybe someone could argue it's a security problem for an invalid GPT being 
> used despite being invalid?
> 
CRC32 isn't a MAC. Anyone who can modify GPT can fix CRC32 as well.
> 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.
> 
Firmware writing to disk without being explicitly asked for it is a
bugware or spyware.
> 
> Chris Murphy
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

signature.asc
Description: OpenPGP digital signature