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]
Date:	Thu, 10 Oct 2013 15:31:14 -0700
From:	Davidlohr Bueso <davidlohr@...com>
To:	Bill Richardson <wfrichar@...omium.org>
Cc:	Doug Anderson <dianders@...omium.org>,
	Josh Triplett <josh@...htriplett.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jens Axboe <axboe@...nel.dk>, Karel Zak <kzak@...hat.com>,
	Matt Fleming <matt.fleming@...el.com>,
	Sean Paul <seanpaul@...omium.org>,
	Olof Johansson <olof@...om.net>
Subject: Re: Regression parsing GPT (EFI) partition tables

On Thu, 2013-10-10 at 14:53 -0700, Bill Richardson wrote:
> I'm about to go offline for a week, but here are some thoughts.
> 
> The GPT spec is over-constrained. It says that the secondary GPT
> header must be in the last LBA of the disk, yet it also says that both
> primary and secondary headers must point to each other using their
> AlternateLBA fields. We don't need both of those rules - and the spec
> is unclear what it means if the headers *don't* point to each other,
> or if they do but from the wrong place.
> 

I completely agree. But I'm concerned about the size of lba, and not the
primary/backup header differences.

> Chrome OS install images are created in a binary file, so the ending
> LBAs are just the last LBA in the binary image, and that's where the
> primary GPT header's AlternateLBA field points. When we dd that image
> onto a USB or SD card and boot it, the secondary GPT header is not at
> the end of the disk. The primary GPT header is otherwise valid, so we
> boot it anyway and the chromeos-install process creates valid primary
> and secondary headers (with cross-pointing AlternateLBA fields) on the
> fixed drive.
> 
> That bootable binary image does have a protective MBR (partition type
> 0xEE), but again the extent of it is only that of the original binary,
> not the USB drive it was copied onto.

Ahh, now that makes a whole lot of sense for this problem. That's why
your size in lba is the same as the backup gpt lba. All in all you're
using the binary file as your "whole disk", instead of the actual disk
itself, so while this is a very out of the ordinary configuration, it is
constant for GPT: this way size in lba == last lba for the _file_.

> 
> Chrome OS BIOS pays no attention *at all* to the legacy MBR, or to the
> AlternateLBA fields of either GPT header. It only looks for the GPT
> headers in LBA 1 and LBA <last>.

Then you should *really* use the force_gpt option, which is there to
bypass any MBR checks, and you can avoid issues like this :) 

Anyway, this is still a regression and I believe we can go ahead and
just warn the user about the case instead of not recognizing the disk.

Bill/Doug, care to send a formal patch (with corresponding comments)?

Thanks,
Davidlohr

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists