From: "Austin S. Hemmelgarn" <ahferroin7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Julius Werner <jwerner-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Davidlohr Bueso <dave-h16yJtLeMjHk1uMJSBkQmQ@public.gmane.org>
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Gwendal Grignou <gwendal-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Subject: Re: [PATCH] block: partitions: efi: Always check for alternative GPT at end of drive
Date: Tue, 26 Apr 2016 10:38:37 -0400 [thread overview]
Message-ID: <571F7D6D.8020209@gmail.com> (raw)
In-Reply-To: <1461632806-5946-1-git-send-email-jwerner-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
On 2016-04-25 21:06, 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
> 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).
At the absolute minimum, we should be logging (at least at a warning
level) that we had to fall back the the backup GPT. If somebody is
dealing with a disk that had a torn write to the primary GPT, that's one
thing, but this could also be caused by any number of other problems
(hardware issues, malicious intent, etc), and we need to log that we
detected corrupted data.
>
> Signed-off-by: Julius Werner <jwerner-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
> block/partitions/efi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/block/partitions/efi.c b/block/partitions/efi.c
> index 26cb624..0d4ca8e 100644
> --- a/block/partitions/efi.c
> +++ b/block/partitions/efi.c
> @@ -625,7 +625,7 @@ static int find_valid_gpt(struct parsed_partitions *state, gpt_header **gpt,
> good_agpt = is_gpt_valid(state,
> le64_to_cpu(pgpt->alternate_lba),
> &agpt, &aptes);
> - if (!good_agpt && force_gpt)
> + if (!good_agpt)
> good_agpt = is_gpt_valid(state, lastlba, &agpt, &aptes);
>
> /* The obviously unsuccessful case */
>
next prev parent reply other threads:[~2016-04-26 14:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-26 1:06 [PATCH] block: partitions: efi: Always check for alternative GPT at end of drive Julius Werner
[not found] ` <1461632806-5946-1-git-send-email-jwerner-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2016-04-26 10:20 ` Karel Zak
2016-04-26 18:33 ` Davidlohr Bueso
[not found] ` <20160426183353.GB16601-95RKjC4jbl+7r5TWoziOLQ@public.gmane.org>
2016-04-26 20:13 ` Julius Werner
2016-04-26 20:34 ` Elliott, Robert (Persistent Memory)
[not found] ` <94D0CD8314A33A4D9D801C0FE68B402963904365-wwDBVnaDRpYSZAcGdq5asR6epYMZPwEe5NbjCUgZEJk@public.gmane.org>
2016-04-26 21:15 ` Davidlohr Bueso
[not found] ` <20160426211547.GC16601-95RKjC4jbl+7r5TWoziOLQ@public.gmane.org>
2016-04-26 21:51 ` Gwendal Grignou
[not found] ` <CAMHSBOW7MBtpVPZdt8yGggUhxk_ca3U+w9Wc-vg5fX7G-jB6mQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-04-27 15:09 ` Karel Zak
2016-04-27 15:45 ` Doug Anderson
[not found] ` <20160427150913.m2vvhtriq27u65tk-xkT7n84Rsxv/9pzu0YdTqQ@public.gmane.org>
2016-04-27 21:44 ` Julius Werner
2016-04-27 6:00 ` Ard Biesheuvel
[not found] ` <CAKv+Gu9UnTnWQt7Q6p3CWbmn8sufcxgYcVo=KD68Wg1=1rrzdw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-04-27 12:59 ` Austin S. Hemmelgarn
2016-04-26 14:38 ` Austin S. Hemmelgarn [this message]
[not found] ` <571F7D6D.8020209-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-26 18:10 ` Davidlohr Bueso
[not found] ` <20160426181018.GA16601-95RKjC4jbl+7r5TWoziOLQ@public.gmane.org>
2016-04-26 19:27 ` Austin S. Hemmelgarn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=571F7D6D.8020209@gmail.com \
--to=ahferroin7-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=dave-h16yJtLeMjHk1uMJSBkQmQ@public.gmane.org \
--cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=gwendal-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=jwerner-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).