Discussion:
[PATCH] EFI: find EFI system partition by legacy MBR partition type
Add Reply
Andre Przywara
2017-07-06 09:14:03 UTC
Reply
Permalink
Raw Message
The UEFI spec allows an EFI system partition (ESP, with the bootloader or
kernel EFI apps on it) to reside on a disk using a "legacy" MBR
partitioning scheme.
But in contrast to actual legacy disks the ESP is not marked as
"bootable" using bit 7 in byte 0 of the legacy partition entry, but is
instead using partition *type* 0xef (in contrast to 0x0b or 0x0c for a
normal FAT partition). The EFI spec isn't 100% clear on this, but it even
seems to discourage the use of the bootable flag for ESPs.
Also it seems that some EFI implementations (EDK2?) even seem to ignore
partitions marked as bootable (probably since they believe they contain
legacy boot code).
The Debian installer [1] (*not* mini.iso), for instance, contains such an
MBR, where none of the two partitions are marked bootable, but the ESP
has clearly type 0xef.
Now U-Boot cannot find the ESP on such a disk (USB flash drive) and
fails to load the EFI grub and thus the installer.

Since it all boils down to the distro bootcmds eventually calling
"part list -bootable" to find potential boot partitions, it seems logical
to just add this "partition type is 0xef" condition to the is_bootable()
implementation.

This allows the bog standard arm64 Debian-testing installer to boot from
an USB pen drive on Allwinner A64 boards (Pine64, BananaPi-M64).
(Ubuntu and other distribution installers don't have a legacy MBR, so
U-Boot falls back to El Torito there).

[1] https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/
Signed-off-by: Andre Przywara <***@arm.com>
---
disk/part_dos.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/disk/part_dos.c b/disk/part_dos.c
index 7ede15e..7aff73d 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -44,7 +44,7 @@ static inline int is_extended(int part_type)

static inline int is_bootable(dos_partition_t *p)
{
- return p->boot_ind == 0x80;
+ return (p->sys_ind == 0xef) || (p->boot_ind == 0x80);
}

static void print_one_part(dos_partition_t *p, lbaint_t ext_part_sector,
--
2.9.0
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Andre Przywara
2017-07-06 13:07:42 UTC
Reply
Permalink
Raw Message
Hi,
Hi,
i am the upstream developer of program xorriso which packs up Debian arm64
ISOs.
To my opinion, if U-boot is used as EFI implementation, then it should
not consider as bootable any "active" MBR partitions or "Legacy BIOS
Bootable" GPT partitions (see is_bootable() in disk/part_efi.c).
First thing to note here is that U-Boot does not really have an
understanding yet of whether it is acting as an EFI implementation or
not. At this stage it simply looks for boot partition *candidates*,
which will then later be examined more closely to find boot scripts or
EFI apps. Adding one more partition to that list should not cause much
harm, I think.
While the proposed change of behavior is an undisputable improvement,
my objection is that the main boot loaders in distro ISOs are GRUB and
SYSLINUX. Both do not expect that the "active" partition gets booted by
the firmware but rather that their own MBR at the start of the ISO gets
started by BIOS or the ESP is brought up by EFI.
The MBR programs in the ISOs do not go on with booting the "active"
partition but rather hop onto the El Torito boot image programs in the ISO.
A second thing to note is that there is some fundamental difference here
between the ARM world and x86.
For ARM U-Boot was so far just piggy-backing on the bootable MBR flag to
find /boot partition candidates. I am not sure if there is actually some
spec or standard covering this behaviour, it was just convenient and
worked quite well in the (mostly embedded) ARM world.
And on ARM U-Boot never considered the "boot code" in a boot sector
(neither on the MBR or on an active partition) - which is probably x86
code anyway.

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.
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? Maybe Simon could shed some light on this?

Cheers,
Andre.
The Legacy BIOS Bootable bit of GPT is explicitely not an EFI boot
indicator. UEFI 2.4 says in table 20 : "UEFI boot manager (see chapter 3)
must ignore this bit when selecting a UEFI-compliant application".
The BootIndicator byte of MBR partitions is explicitely not for EFI.
Table 14 says: "This field shall not be used by UEFI firmware."
So if "active" partitions are present in GRUB or SYSLINUX equipped ISOs
they are under no circumstances intended for being booted.
Currently debian ISOs for arm64 have no "active" partition. But that's
an inner implementation detail. E.g. HDD bootable ISOs for x86 do have
the "active"/bootable flag on the ISO 9660 partition out of tradition to
appease mad BIOS implementations.
It is well possible to combine x86 BIOS and arm64 EFI boot equipment
in the same ISO image. So the need for an "active" partition might arise.
Have a nice day :)
Thomas
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Simon Glass
2017-07-07 03:57:23 UTC
Reply
Permalink
Raw Message
Hi Andre,
Post by Andre Przywara
Hi,
Hi,
i am the upstream developer of program xorriso which packs up Debian arm64
ISOs.
To my opinion, if U-boot is used as EFI implementation, then it should
not consider as bootable any "active" MBR partitions or "Legacy BIOS
Bootable" GPT partitions (see is_bootable() in disk/part_efi.c).
First thing to note here is that U-Boot does not really have an
understanding yet of whether it is acting as an EFI implementation or
not. At this stage it simply looks for boot partition *candidates*,
which will then later be examined more closely to find boot scripts or
EFI apps. Adding one more partition to that list should not cause much
harm, I think.
While the proposed change of behavior is an undisputable improvement,
my objection is that the main boot loaders in distro ISOs are GRUB and
SYSLINUX. Both do not expect that the "active" partition gets booted by
the firmware but rather that their own MBR at the start of the ISO gets
started by BIOS or the ESP is brought up by EFI.
The MBR programs in the ISOs do not go on with booting the "active"
partition but rather hop onto the El Torito boot image programs in the ISO.
A second thing to note is that there is some fundamental difference here
between the ARM world and x86.
For ARM U-Boot was so far just piggy-backing on the bootable MBR flag to
find /boot partition candidates. I am not sure if there is actually some
spec or standard covering this behaviour, it was just convenient and
worked quite well in the (mostly embedded) ARM world.
And on ARM U-Boot never considered the "boot code" in a boot sector
(neither on the MBR or on an active partition) - which is probably x86
code anyway.
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.
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? Maybe Simon could shed some light on this?
The recommended way is to load FIT with containing a 32-bit or 64-bit
vanilla kernel binary (which U-Boot can execute directly), and a
setup.bin file (for legacy reasons the kernel requires this). Verified
boot can be enabled if required.

See doc/uImage.FIT/x86-fit-boot.txt for details.

Regards,
Simon
Post by Andre Przywara
Cheers,
Andre.
The Legacy BIOS Bootable bit of GPT is explicitely not an EFI boot
indicator. UEFI 2.4 says in table 20 : "UEFI boot manager (see chapter 3)
must ignore this bit when selecting a UEFI-compliant application".
The BootIndicator byte of MBR partitions is explicitely not for EFI.
Table 14 says: "This field shall not be used by UEFI firmware."
So if "active" partitions are present in GRUB or SYSLINUX equipped ISOs
they are under no circumstances intended for being booted.
Currently debian ISOs for arm64 have no "active" partition. But that's
an inner implementation detail. E.g. HDD bootable ISOs for x86 do have
the "active"/bootable flag on the ISO 9660 partition out of tradition to
appease mad BIOS implementations.
It is well possible to combine x86 BIOS and arm64 EFI boot equipment
in the same ISO image. So the need for an "active" partition might arise.
The recommended
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...