[U-Boot] [PATCH 5/7] disk: Allow alternate EFI partition signature

[Stephen Warren]

On 10/15/2012 11:17 AM, Stefan Reinauer wrote:
> On Mon, Oct 15, 2012 at 8:19 AM, Stephen Warren <swarren at wwwdotorg.org
> <mailto:swarren at wwwdotorg.org>> wrote:
> 
>     On 10/12/2012 06:26 PM, Simon Glass wrote:
>     > From: Stefan Reinauer <reinauer at chromium.org
>     <mailto:reinauer at chromium.org>>
>     >
>     > ChromeOS uses a GPT partition table to partition the disk.
>     > However, Windows will refuse to install on a GPT partitioned
>     > disk if there is no EFI available (Even if there is an MBR, too)
>     > To hide the GPT partition table from Windows, we need to write
>     > it with a header magic other than "EFI PART". To support old
>     > and new systems, Check for the magic string "CHROMEOS" too.
> 
>     Surely if you wanted to install Windows on a disk containing ChromeOS,
>     you would just wipe the disk and re-partition it? I suppose perhaps
>     you're talking about dual-boot though?
> 
> 
> Yes, this is only required if we're dual-booting on Windows and ChromeOS
> on the same disk.
> 
>     Either way, it doesn't see like a good idea to be using non-standard EFI
>     signatures - especially if the idea is to hide the GPT from Windows, and
>     presumably then have Windows use the MBR partitions, since that will end
>     up with a decidedly non-standard partition setup; some partitions will
>     only be represented in the MBR (those Windows creates) and some in GPT
>     (presumably whatever ChromeOS created before).
> 
> 
> Yes, you will have to create a hybrid partition setup to make this work.
> It is unfortunate that Windows enforces this and there is no real way
> around it.

Is this something common that someone using upstream U-Boot would care
about, or is it something specific that should be contained in a
ChromeOS U-Boot tree? I'm worried that applying this patch will just (a)
support a situation that'll be very confusing to the user and (b)
slightly de-stabilizes the U-Boot code in other situations by allowing
non-standard (perhaps considered corrupt even) EFI partition tables.

Still, I suppose I won't be impacted by case (a) so I probably shouldn't
care much about it, and case (b) hopefully won't cause practical
problems (famous last words), so I'm not opposed to this patch, it just
feels slightly risky to me.