linux-kernel - Re: [PATCH 0/8] partitions/efi: detect hybrid mbrs

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:	Tue, 06 Aug 2013 15:39:37 -0700
From:	Davidlohr Bueso <davidlohr@...com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Jens Axboe <axboe@...nel.dk>, Matt Domsch <Matt_Domsch@...l.com>,
	Jim Hull <jim.hull@...com>, Karel Zak <kzak@...hat.com>,
	Peter Jones <pjones@...hat.com>,
	Chegu Vinod <chegu_vinod@...com>,
	Aswin Chandramouleeswaran <aswin@...com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/8] partitions/efi: detect hybrid mbrs

On Tue, 2013-08-06 at 14:16 -0700, Andrew Morton wrote:
> On Mon,  5 Aug 2013 22:21:08 -0700 Davidlohr Bueso <davidlohr@...com> wrote:
> 
> > This patchset teaches the kernel about hybrid master boot records (MBRs), one of
> > the most common issues with GUID partition tables, as a workaround to layout
> > disk partitions to be compatible with both EFI and legacy MBR based systems.
> > Except for adding more pmbr checks, to better comply with the UEFI/GPT specs, the
> > functionality is left unchanged - we only inform (through debug) the user about
> > the used MBR scheme. While it is true that these restrictions can be bypassed when
> > forcing gpt, this is not the correct or default way of doing things, complicating
> > users furthermore. More details are in the individual patches.
> 
> Patches look nice, although I'll cheerily admit to not having a clue
> what they do.  What is a "hybrid MBR" anyway?

Not having to know about hybrid MBRs is actually a good thing, they can
be quite a pain :)

I tried to explain more carefully what this particular MBR scheme is,
why it exists and why we cannot do anything about it in patch 5, but
perhaps it wasn't left clear and should have been in the cover letter as
well. Here's a brief summary:

EFI's GPT disklabels present a number of benefits to the traditional MBR
such as not having to deal with CHS addressing, better data integrity
(including a backup header) and 64bit LBA addressing (which allows
partitions to go beyond the 2Tb limit all the way up to 9.4 Zb), among
others. These nice features don't come free, however, having to deal
with older legacy systems (normally BIOS-based) that only use MBR, and
do not know about GPT. For example, users (like myself), who have an EFI
system (say a mac), dual booting with an older, non-EFI version of
Windows. While OSX knows GPT and uses the GPT partition(s), Windows
doesn't, so I cannot dual boot without creating a hybrid MBR - the
standard protective MBR (pMBR) won't allow Windows to boot. This hybrid
MBR will extend the regular pMBR (containing a 0xEE GPT partition) so
that it contains up to three primary partitions that point to the same
disk locations that the GPT partitions point to.

Hybrid MBRs are *unofficial* workarounds to the GPT specs, but necessary
for backward compatibility. Furthermore, most bootloaders are now
acknowledging this kind of scheme.

These patches only detect these configurations, and it's important that
the kernel can differentiate between hybrid and protective MBRs to
better detect correctly built pMBRs.

> Someone's editor seems to replace tabs with spaces so the patches
> generate quite a checkpatch storm.  Please use checkpatch.

Sorry, will do so in the future. I guess all patches from me have this
problem.

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/