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

[Andre Przywara]

Hi,

On 06/07/17 15:31, Alexander Graf wrote:
> 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 ;).

I totally agree. The U-Boot code itself does not really impose a boot
policy, that is at the moment just covered by the *default* boot
scripts, which implement some heuristic Do-what-I-mean(TM) policy.

Anyone with a desperate wish for being 100% EFI compliant is always
welcome to just change this boot script for their platform or even
build. One could even implement a menu with the typical PC BIOS choice
of "UEFI only, UEFI first, then legacy, legacy only", if one really
feels like.
However all of those policies would probably base their actions on the
"part list -bootable" result, which is what this patch extends to make
it actually possible to implement properly.

>>> 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 :).

I agree that "efi/boot/bootaa64.efi" leaves little room for
interpretation ;-)

Cheers,
Andre.

>> ---------------------------------------------------------------------
>> 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
>