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: <CAD=FV=WCZh-RuUghzwTkDKvVFjpLNR7RW6H_hNbS15ZqWeBjTg@mail.gmail.com>
Date:	Wed, 27 Apr 2016 08:45:41 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Karel Zak <kzak@...hat.com>
Cc:	Gwendal Grignou <gwendal@...omium.org>,
	Davidlohr Bueso <dave@...olabs.net>,
	"Elliott, Robert (Persistent Memory)" <elliott@....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>
Subject: Re: [PATCH] block: partitions: efi: Always check for alternative GPT
 at end of drive

Hi,

On Wed, Apr 27, 2016 at 8:09 AM, Karel Zak <kzak@...hat.com> wrote:
> On Tue, Apr 26, 2016 at 02:51:01PM -0700, Gwendal Grignou wrote:
>> Julius and I were looking at the code when we spotted the issue.
>>
>> As Julius said, "just pass a boot param", is not easy on certain
>> machines, like phone. It is not user friendly either.
>> The system won't boot at all, a typical user will have to do a full
>> reinstall to fix the error.
>
> And how typical user will fix the problem with corrupted primary
> header after successful boot? I mean, use alternative header (without
> force_gpt) is a good idea if we know that user will not ignore the
> problem. The current solution is to force user to do anything.
>
> It would be nice to have support for this issue in userspace
> and switch for example to single user mode, or so...
>
> I'm also have doubts that printk() is the best way how to report
> this issue to userspace if we want to trigger any action :-)

Presumably:

* We ended up in this situation because something (auto update,
partition resizer, etc) was making changes to the GPT and got
interrupted (power cycle, crash, etc).

* The something that was making changes will run again after the
system boots up.

* The something that was making changes will presumably be smart
enough to figure out how to fix things up.

* If we can't even boot up, that something has no chance...

...or, if we ended up in this situation because a cosmic ray hit our
storage device and corrupted the primary GPT then I'd say that we
should keep using the alternate and not care that userspace won't do
anything to fix it.  Hopefully cosmic rays are super rare and the
changes of a second one hitting and killing the secondary GPT are slim
to none.  If you're using this disk in outer space and cosmic rays are
common, presumably you've got some massive ECC going on and maybe you
even have userspace that expects periodic sector failures and knows
how to handle it.

-Doug