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] [day] [month] [year] [list]

Message-ID: <CAODwPW9CyyhfB-0e_xefaE8NbLQ8Yi2OCRKeXqZtdTq6CDyqLg@mail.gmail.com>
Date:	Wed, 27 Apr 2016 14:44:11 -0700
From:	Julius Werner <jwerner@...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>,
	Doug Anderson <dianders@...omium.org>
Subject: Re: [PATCH] block: partitions: efi: Always check for alternative GPT
 at end of drive

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 :-)

Holding the whole system hostage and forcing manual action is *not*
user-friendly behavior. Linux is no longer just something for hobbyist
hackers to install on their converted Windows machines at home... it
is a mature, modern operating system kernel used on a wide range of
devices (server farms, phones, embedded systems, etc.) and it should
behave like one. Not all of these platforms necessarily make it easy
for the user to drop into grub and add some command line parameters,
and it's the kernel's job to provide a suitable environment for all of
them so that policy decisions can be left to userspace.

So yes, userspace should resolve this problem, but in order to do that
you need to allow userspace to boot first! dmesg is one suitable way
to communicate the problem, and there are others which I wouldn't be
opposed to either, but no matter which channel we choose the kernel
still has to continue booting to allow the rest of the OS to deal with
it. Whether to ignore, silently repair or fail to boot from a
corrupted primary GPT is a policy decision and it should be made in
user space... if you need to retain the current behavior, it's easy to
add an init script that greps for GPT warnings and hangs to your
distro.