Re: grub mishandles corrupt/missing primary GPT

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3148 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]