[syslinux] syslinux mkisofs hard-disk-boot isohybrid

[Thomas Schmitt]

Hi,

i wrote:
> > The boot success with UEFI and -cdrom must have other reasons. I suspect
> > the BIOS emulation of the firmware.

Pascal wrote:
> I used "OVMF-pure-efi.fd" and not "OVMF-with-csm.fd" (from
> https://www.kraxel.org/repos/jenkins/edk2/ [www.kraxel.org])

The not UEFI specs compliant path of finding file bootx64.efi seems
to use El Torito device emulation, even on hard disk.
Reading
  http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt
i would expect this to happen by the DXE step.

I see in
  https://github.com/tianocore/edk2/blob/18b00c8c8773e62b1e2c4a36f490996325570b67/MdeModulePkg/Universal/Disk/PartitionDxe/ElTorito.c
a case distinction where ELTORITO_HARD_DISK is _not_ handled by the
code part which says:
  "unsupported El Torito boot media type"
(This overextents UEFI specs which say that the EFI System partition
shall be announced as "no-emulation" El Torito boot image.)

A similar case distinction leads to registration as "partition" in
function FatFindEltoritoPartitions() of
  https://github.com/tianocore/edk2/blob/18b00c8c8773e62b1e2c4a36f490996325570b67/FatPkg/FatPei/Part.c
where function FatFindPartitions() first looks for an MBR and then for
El Torito without distinguishing the medium type.
(This overextents UEFI specs which do not mention El Torito outside
optical media.)

The function FatFindEltoritoPartitions() does not distinguish between
Platform Id 0x00 (x86 BIOS) and 0xEF (UEFI).
(This overextents UEFI specs which say that El Torito boot images shall
have Platform Id 0xEF.)

I did not yet identify the code part, which then looks into the registered
El Torito emulated hard disk "partition" for a partiton table leading
to the FAT filesystem with bootx64.efi.
This is similar to the EBR mechanism of extended partitions. So possibly
function PartitionInstallMbrChildHandles() in
  https://github.com/tianocore/edk2/blob/18b00c8c8773e62b1e2c4a36f490996325570b67/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
is a valid suspect for that last step.

Now the firmware would see an MBR partition of type 0xEF and have reason
to look into it for /efi/boot/bootx64.efi.

This would need three instances of ignoring written UEFI specs.


If not your test results would support this theory, then i would believe
this to be dead code in the edk2 tree. But together with your results
my frightening suspicion seems realistic.

It is frightening because it might execute code which was not intended
for EFI instead of a real EFI boot program which is marked in an UEFI
compliant way.


Have a nice day :)

Thomas