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: <20160426211547.GC16601@linux-uzut.site>
Date:	Tue, 26 Apr 2016 14:15:47 -0700
From:	Davidlohr Bueso <dave@...olabs.net>
To:	"Elliott, Robert (Persistent Memory)" <elliott@....com>
Cc:	Karel Zak <kzak@...hat.com>, Julius Werner <jwerner@...omium.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-block@...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, Elliott, Robert (Persistent Memory) wrote:

>The UEFI specification is not ambiguous - you should always look
>for the backup GPT Header at the last LBA:
>
>"Two GPT Header structures are stored on the device: the primary
>and the backup. The primary GPT Header must be located in LBA 1
>(i.e., the second logical block), and the backup GPT Header must
>be located in the last LBA of the device."
>
>If the primary GPT Header is corrupted (e.g., CRC is bad), you
>cannot trust any fields in it, including the Alternate LBA field.

I'm well aware of this, and is really what I meant with 'ambiguous'
(which was ambiguous in itself). All I'm arguing is that I don't see
a solid reason to change the default, when we have (and have had for
a long time) the gpt param alternative.

>The Alternate LBA field is there to help you tolerate failures
>while growing or shrinking the block device size (not important
>for individual physical drives, but an issue for logical drives
>presented by RAID controllers).

I have nothing against the agpt, just pass a boot param and voila,
you can use it. This is not some sort of recent regression we are
talking about here. How is this such a burden all of a sudden?

Thanks,
Davidlohr