Re: [Libcdio-devel] [PATCH 1/4] Add case insensitive _cdio_stricmp and _cdio_strnicmp function calls

[Pete Batard]

Hi Thomas,

On 2024.01.29 14:35, Thomas Schmitt via Libcdio-devel wrote:
> - About all legacy PC-BIOS boot images of Linux installation ISOs will
>    be shown with the recorded load size of 2048 bytes, although the
>    file size of these images (x86 programs) is in the range of several
>    dozen KiB.

And about all legacy PC-BIOS boot images are therefore deviating from 
the El Torito specs then, whereas this patchset concerns itself with 
El-Torito support.

> - Some few EFI boot images of Linux installation ISOs will be shown with
>    the recorded sizes of 0 or 512 bytes, which according to UEFI means
>    "very large, assume it to reach up to the end of the device".
>    The real size is the size of the FAT filesystem in such an image.
>    v2:
>    This risk is avoided in v2 at the cost of the smaller risk of
>    encountering a legacy PC-BIOS image of size 1. (That was the size of
>    the image in the test ISO for v1.)

The actual risk is:
1. Encountering an image of size 1
2. That is the one image, from all the El Torito images, that has the 
the max LSN, but that doesn't reside at the end of the ISO.
3. On an ISO that has more than 32 MB of content after that LSN and the 
end of the ISO.

In other words, the current proposal will actually properly process 
images of size 1, unless you went out of your way to craft an ISO where 
you have a 512-byte El Torito image, that is not followed by anything 
else El Torito, but that you placed at the beginning of your media.

*Exceedingly* unlikely to happen with real life images, especially if 
you are using standard mastering software, that, obviously, has a *very 
vested interest* in always placing El Torito images at the end of the 
volume, so that they can handle the UEFI exception...

> - Some few EFI boot images will be shown with size 32 MiB - 512 bytes,
>    although they are actually larger. (That's a flaw of the ISO, though.)

Yes. As I said, if we believe it's important to handle this special 
completely out of specs case, we can easily do so.

> - The intended audience firmware (Platform Id in El Torito: legacy BIOS
>    or EFI) cannot be surely deduced from the presentation of the image
>    files in the /boot pseudo-directory. One would have to guess from
>    size and content.

Yes. But not doing so allows us to handle the UEFI "addendum" to the 
specs, as well as potentially people who, from seeing UEFI do it, 
decided to use 0 or 1 as a means to go over the 32 MB limit for non 
UEFI. Especially, if using 0 as a size, which would make for an invalid 
size if you follow the specs, it makes a lot of sense do disregard the 
platform id, and assume > 32 MB.

> - New observation:
>    I wonder about the uppercase/lowercase differences between the test ISO
>    from patch 4 and a Debian netinst ISO:
>      $ ./src/iso-info --no-header --quiet -l test/data/eltorito.iso
>      ...
>      /[boot]/:
>       - [LSN     26]       512 Jan 23 2024 13:25:09  0-boot-noemul.img
>      ...
>      $ ./src/iso-info --no-header --quiet -l debian-12.2.0-amd64-netinst.iso
>      ...
>      /[BOOT]/:
>        - [LSN   5863]      2048 Oct 07 2023 10:32:09  0-Boot-NoEmul.img
>        - [LSN   1119]   9715712 Oct 07 2023 10:32:09  1-Boot-NoEmul.img
>      ...
>    The test ISO has no Rock Ridge or Joliet. Is that enough reason to
>    flatten the pseudo-file names ?

libcdio internally flattens file names if Rock Ridge or Joliet is not 
used. Whether this is warranted or not is a different discussion.

>    If so: Does this meet Pete's usage intentions ?

I'm just following the libcio constraints. I could have created a Joliet 
ISO, but decided it wasn't worth it.

> --------------------------------------------------------------------------
> [PATCH 3/4] Add --no-el-torito option to iso-info
>
> - In my own projects i would rather disable the new feature by default
>    and offer an option --el-torito.

*STRONGLY* disagree for the reasons I explained earlier.

People who have ever used 7-zip, and there are a lot of them, do expect 
El Torito images to be listed by default.

So, IMO, the principle of least surprise, when it comes to user 
experience, is to have El Torito extensions and virtual images enabled 
by default.

> - New objection:
>    The proposed ISO image is very unrealistic by the load size 1 of its
>    only boot image.

As I mentioned earlier, it is designed to test the case where we have 
images that are not a multiple of ISO_BLOCKSIZE. And, when it comes to 
v2, it now also allows us to validate that we aren't over greedy with 
the auto-extension of images, which I see as a bonus.

> Especially it does not test the use case which caused
>    Pete to develop the patch set and which has chances to show realistic
>    sizes: An EFI boot image, which contains a FAT filesystem.
>    (One could make an ISO with a real isolinux.bin from Debian netinst ISO
>     as legacy boot image of 38912 bytes and a minimal FAT filesystem as
>     EFI boot image.)

Well, if anybody wants to expand on the El Torito testing, feel free to 
do so. I personally wouldn't mind having more images, but I am not 
planning to add these myself, and I very much see the current test image 
as something we do want to keep, for the reasons I explained above, 
where having a 521-byte image enables us to validate code paths we do 
want to validate.

> Some of my objections are about design decisions. Pete strives for
> compatibility with 7z rather than for exposing all El Torito aspects.

That's not correct. I strive to provide El Torito support with libcdio 
on a cost effective basis, and (AFAIK) since 7-zip did invent the 
concept of listing El Torito images as virtual images, I purposefully 
choose not to go on a "Not Invented Here" route, that is the plague of 
end users everywhere, and follow what 7-zip does in the process.

> Further the patch knowingly risks wrong results.

And I'll be waiting for real life images that show wrong results, and 
amend the code then (but only then, since I do foresee that the current 
codeset will not actually cause issues unless you purposefully design 
ISOs to specifically make it break).

Regards,

/Pete