Re: [PATCH] block: partitions: efi: Always check for alternative GPT at end of drive

[Davidlohr Bueso]

On Tue, 26 Apr 2016, Karel Zak wrote:

> On Mon, Apr 25, 2016 at 06:06:46PM -0700, Julius Werner wrote:
> > The GUID Partiton Table layout maintains two synonymous partition tables
> > on a block device, one starting in sector 1 and one in the very last
> > sectors of the block device. This is useful if one of the tables gets
> > accidentally corrupted (e.g. through a partial write because of an
> > unexpected power loss).
> >
> > Linux normally only boots if the primary GPT is valid. It will not even
> > try to find the alternative GPT to an invalid primary one unless the
> > "gpt" command line option forces more aggressive detection. This doesn't
> > really make any sense... if the "gpt" option is not set, the code
> > validates the protective or hybrid MBR in sector 0 anyway before it even
> > starts looking for the actual GPTs. If we get to the point where a valid
> > proctective or hybrid MBR was found but the primary GPT was not found
> > (valid), checking the alternative GPT is our best bet: we know that this

'best bet' in a kernel is not enough :) Which is why userland tools can fix
and/or do any sort of crazy stuff with the backup and recover the primary etc etc.

> > block device is meant to use GPT (because any other partitioning system
> > would've presumably overwritten sector 0), and we know that if the
> > alternative GPT is valid it should contain more accurate information
> > than parsing the protective/hybrid MBR with msdos_partition() would
> > yield (which would otherwise be what happens next).

> I guess "force_gpt" (and "gpt" on kernel command line) exists to force
> users to think and care about a reason why the device has unreadable
> (broken) primary GPT header.

Yes, from find_valid_gpt():

* If the Primary GPT header is not valid, the Alternate GPT header
* is not checked unless the 'gpt' kernel command line option is passed.
* This protects against devices which misreport their size, and forces
* the user to decide to use the Alternate GPT.

... so users are at least forced in some way to think about this.

> It seems like bad (and dangerous) idea to silently ignore corrupted
> primary GTP header and boot from such device.

Yeah, there's no way in hell I trust a backup gpt in kernel space.
We simply have no way of distinguishing between good and bad devices.

> And note that alternative GPT header and the end of the device is a
> just guess. The proper location of the alternative header is specified
> with-in primary header (pgpt->alternate_lba). The header at the end of
> the device (as used for "force_gpt") is a fallback solution only.

And this only illustrates the ambiguity of the backup.

Thanks,
Davidlohr