[U-Boot] [PATCH] EFI: find EFI system partition by legacy MBR partition type

[Alexander Graf]

On 07/06/2017 04:16 PM, Thomas Schmitt wrote:
> Hi,
>
> Andre Przywara wrote:
>> U-Boot does not really have an
>> understanding yet of whether it is acting as an EFI implementation
> If you use it to boot an ISO by its GRUB or SYSLINUX EFI equipment,
> then you ask it to act as EFI implementation.
> Maybe a compile time switch could restrict U-Boot to that role before
> it gets written to the hardware where it shall be the EFI firmware ?
>
> (Sorry, i am entirely software guy. Please don't laugh too loud about my
>   idea of hardware and its relation to U-boot.)

If we really want to make it follow the EFI boot flow 100%, we probably 
need something smarter than the boot scriptlet we have today. We would 
also need to support boot from NVram stored devices for example. For 
now, I consider the boot target finding mechanism more of a best effort 
thing ;).

>
>> Does U-Boot actually support chain-loading boot sectors on x86? Or does
>> it entirely focus on loading either EFI apps or Linux kernels / U-Boot
>> boot scripts?
> Hmm. From its use of the "active" flag of MBR partitions i maybe hastily
> concluded that it would load and run what wikipedia calls the VBR of the
> partition in
>    https://en.wikipedia.org/wiki/Master_boot_record#System_bootstrapping
>
> If U-Boot looks into the "active" partition's filesystem for boot-worthy
> programs, then my objections and the following reasoning are possibly void.

Yup.

> (One would still have to investigate whether files in ISO images might
>   be mistaken as boot-worthy although the ISO producer did not intend them
>   for being started.)

Well, nothing starts ISOs. Worst case there's an EFI binary at the 
removable media location on an iso - and in that case I surely hope the 
creator did intend that to get started :).

> ---------------------------------------------------------------------
> So only in case the "active" partition's VBR can indeed get chainloaded:
>
> The reason why i give objections is that i want to keep the wiggle room
> for bootable ISO 9660 images as wide as possible. Any further assumption
> by the boot environment might block future improvements of such ISOs.

Today U-Boot really only looks for known locations of bootable files. It 
does not execute random binary code straight from partitions or raw 
block devices. So I think we're safe on that front.

>
>
>> Adding one more partition to that list should not cause much
>> harm, I think.
> Your point is supported by the fact that in most x86 HDD bootable ISOs
> the ISO 9660 partition is the "active" one and starts at LBA 0, thus
> having the image MBR as first block. Should work therefore.
>
> But LBA 0 as MBR partition start angers partition editors. In GPT it
> is plainly illegal (although happily used). So i try to push producers of
> GNU/Linux distro ISOs to have the ISO 9660 partition start at LBA 64
> (counted with 512 byte blocks). At least the normal SYSLINUX isohybrid
> MBR will not work if started from a partition with non-zero offset.
>
> In any case the ISO producers are not necessarily aware that an "active"
> flag might cause the start of the partition VBR.

It shouldn't, I agree. The only thing that happens based on the active 
flag here is that U-Boot tries to identify the file system on said 
partition and then tries to load hard coded file names from it.

>
>> Now I am not sure how this maps to the combination of U-Boot and x86 - I
>> am not very familiar with the combination of those two.
> UEFI specs invite to have boot programs for various processor architectures
> in the same ESP. Currently i only know of ISOs which combine 32-bit x86
> and 64-bit x86.
>
> But if one adds a set of ARM executable binaries to the ISO filesystem
> and lets /EFI/BOOT/BOOTAA64.EFI of the ESP start up GRUB with a
> separate ARM-specific grub.cfg, then one can well put together a rescue
> image for DVD or USB-stick which works for x86 BIOS, for x86 EFI in both
> word sizes and also for ARM (in both word sizes, if desired).

I'm fairly sure we can easily put together a disc that can be booted by 
BIOS x86, BIOS x86_64, UEFI x86(_64), edk2 based UEFI on ARM(64) and 
U-Boot based UEFI on ARM(64).


Alex