Re: [Libcdio-devel] [PATCH 2/4] Add El Torito virtual boot image support

[Pete Batard]

On 2024.01.25 07:42, Thomas Schmitt via Libcdio-devel wrote:
> Hi,
>
> something i forgot to mention yesterday:
>
>    $ xorriso -indev openSUSE-13.1-NET-x86_64.iso -report_el_torito plain
>    ...
>    El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
>    El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4        4238
>    El Torito boot img :   2  UEFI  y   none  0x0000  0x00      1          70
>    El Torito img path :   1  /boot/x86_64/loader/isolinux.bin
>    El Torito img opts :   1  boot-info-table isohybrid-suitable
>    El Torito img path :   2  /boot/x86_64/efi
>    ...
>
> The size of the EFI boot image is recorded in the boot catalog as 1, which
> complies to UEFI-2.8:
>
>    13.3.2.1 ISO-9660 and El Torito
>    [...]
>    If the value of Sector Count is set to 0 or 1, EFI will assume the
>    system partition consumes the space from the beginning of the
>    “no emulation” image to the end of the CD-ROM.

Well, if you have formal specs to back it up, that indeed changes thing.

Do you know if the El Torito specs were ever updated to reflect this?

> This is necessary if the EFI partition is larger than 65535 * 512 bytes
> = 32 MiB - 512.

Indeed. I was wondering about that size limit, and you've now explained 
how this is addressed.

> Some misguided ISO producers use 65535 instead of 0 or 1:
>
>    slint64-current-goofiboot-1.4.0.iso
>
>    El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
>    El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4       32807
>    El Torito boot img :   2  UEFI  y   none  0x0000  0x00  65535          39
>    El Torito img path :   1  /isolinux/isolinux.bin
>    El Torito img opts :   1  boot-info-table isohybrid-suitable
>    El Torito img path :   2  /efi.img

Hmmm. So we're going to decide that the chances of someone creating a 
32MB - 512 image, because they read the El Torito specs and went for the 
maximum allowed value are lower than the chances of someone abusing the 
specs?

Or do we interpret the UEFI specs to mean that this only ever applies if 
the platform ID is set to 0xef and that, if platform ID is set to 
anything else, then 1 or 65535 are to be interpreted verbatim.

Personally, it kinda pisses me off that UEFI didn't go only for (size == 
0) => image is read till the end of the volume, and had to also shoehorn 
1 (but somehow not 65535) in there, since:
- They were the specs makers, so they could set/invalidate whatever they 
wanted.
- Obviously a size 0, while allowed by the El Torito specs, made no 
real-life sense (and they didn't define the field as num sectors - 1).

There was no need to throw a 1 in there, outside of trying to appease 
people who were already abusing the specs.


And I can actually see some real-life scenarios (not UEFI though) where 
someone wants to use a 512-byte bootloader to just print a legacy 
message on boot ("Do not leave this media in your CD drive - Please 
return it").

As far as I'm concerned, I think we need to handle 2 branches: verbatim 
for platform ID != 0xef and till the end of the media for platform ID == 
0xef (with 65535 also added to that branch, but that branch only, for 
good measure). Otherwise, we could try to figure out the max LSN used by 
the ISO, to validate if the boot image is at the end, which would then 
tell us if that 1 or 65535 is to be interpreted verbatim or not, 
regardless of type, but that would be both tricky to implement and 
overkill...

> (I take these examples out of the log of my regression test which repacks
> about 200 GB of bootable ISOs whenever i change the boot related code in
> libisofs.)
>
>
> > so, on real-life El-Torito media, you will find:
> > - [BOOT]/0-Boot-NoEmul.img (the initial 2048 byte loader)
> > - [BOOT]/1-Boot-NoEmul.img (the rest of the image)
>
> Urm, in the usual Linux distro installation ISO this will be the BIOS
> boot image (shortened) and the EFI system partition image.
>
> The short size of the BIOS image was chosen by the boot loader programmers
> to circumvent a bug in old BIOSes, which refused to load any other size.
> The rest of the BIOS image is directly following the first 2048 bytes
> and is not announced by the boot catalog.
> Its presence and size can only be told if the boot info table is read.
>
>
> I understand your patch is only striving for EFI boot images.
> That would be ok for me, if it would exclude other images from being
> mapped to the pseudo-directory and if it would get the EFI image size
> rules correctly.

Yeah, I agree that we need to take care of the EFI image size rules. As 
to other images, again, we are following what 7-zip does so I don't 
think we want to exclude stuff that 7-zip doesn't exclude though, 
obviously, we are currently more restrictive than 7-zip when it comes to 
the boot media types we handle.

For what is worth, here's the naming scheme 7-zip uses for boot media 
type -> Virtual name conversion:

https://github.com/mcmilk/7-Zip/blob/master/CPP/7zip/Archive/Iso/IsoIn.cpp#L22-L29

And it uses "Boot"/"NoBoot" for Boot indicator:

https://github.com/mcmilk/7-Zip/blob/master/CPP/7zip/Archive/Iso/IsoIn.cpp#L50

> (For being able to tell the intented firmware system, you'd need to
> interpret the Validation Entry and the Section Header Entries for
> platform ids.)

Again, I'm taking this to mean that the abuse of El Torito specs is only 
intended to apply if platform ID is EFI.

Now, while I agree that we need to take care of the UEFI exception, at 
this stage, I have no idea when I'll get a chance to do that. It may be 
a couple of weeks.

Regards,

/Pete

> > Gotta love how on one hand I'm kind of being chastised for taking shortcuts
> > with the specs, but, when I follow the specs exactly, that make absolutely
> > zero mention about a lower limit for num_sectors, I'm being told about
> > "tradition".
>
> Hey, this is a technical discussion about El Torito and your patch.
> No offense intended.
>
> The existing habits around boot loaders are of importance. The world of
> legacy BIOS nearly entirely consists of habits.
>
>
> Have a nice day :)
>
> Thomas