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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160426183353.GB16601@linux-uzut.site>
Date:	Tue, 26 Apr 2016 11:33:53 -0700
From:	Davidlohr Bueso <dave@...olabs.net>
To:	Karel Zak <kzak@...hat.com>
Cc:	Julius Werner <jwerner@...omium.org>, linux-efi@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
	Gwendal Grignou <gwendal@...omium.org>,
	Doug Anderson <dianders@...omium.org>
Subject: Re: [PATCH] block: partitions: efi: Always check for alternative GPT
 at end of drive

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