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