Hi, i wrote > > [...] 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.
Peter Batard wrote: > Do you know if the El Torito specs were ever updated to reflect this? Not that i would have noticed. I still use “El Torito” Bootable CD-ROM Format Specification Version 1.0 January 25, 1995 Phoenix (R) IBM It wasn't updated for DVD or Blu-ray either. Everybody just extrapolated the specs and was in sync with every other involved party. > 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? If you first verify that the boot image is for EFI, i would propose to look into the FAT filesystem whenever the El Torito Load Size is smaller than the smallest meaningful FAT filesystem or larger than 65532 (= 65536 - 4, because it is the smallest possible load size which is divisible by 4). > Or do we interpret the UEFI specs to mean that this only ever applies if the > platform ID is set to 0xefi This special meaning of 0 and 1 is only defined in UEFI. I am not aware that it was ever interpreted that way in legacy BIOS. > and that, if platform ID is set to anything else, > then 1 or 65535 are to be interpreted verbatim. The problem is that the field in the El Torito catalog was defined in 1995 as: Sector Count. This is the number of virtual/emulated sectors the system will store at Load Segment during the initial boot procedure. This definition does not describe the size of the boot image but only the size of the data to be transferred from CD-ROM to RAM. So BIOS programmers felt entitled to implement only the capability for a small read, which then caused boot loader programmers to understate the size of their no-emulation images. This understatement to size 4 usually is accompanied by a boot info table. ------------------------------------------------------------------------ Anecdote. Not a proposal: In xorriso i make a different approach by estimating the boot image size from other information in the ISO. Best is of course if the image is also represented as data file in the ISO. Then i can take its file size. Strange enough: The EFI boot image of openSUSE-13.1-NET-x86_64.iso is also represented as file /boot/x86_64/efi with just 4,194,304 bytes of size. So it would not have been necessary to set the Load Size to unlimited. The EFI image in slint64-current-goofiboot-1.4.0.iso is 64 MiB of size, i.e. too big for the 16 bit field in the boot catalog. More guesswork is needed with hidden boot images, where i look at the start addresses of all known objects in the ISO (file or not) and assume that the size reaches from the start LBA of the boot image to the start of the next known object (e.g. the next boot image, the start of the directory tree). Hiding boot image files is not usual in GNU/Linux. But for example Fedora-Server-dvd-x86_64-37-1.7.iso does so: El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x0000 0x00 4 562 El Torito boot img : 2 UEFI y none 0x0000 0x00 20352 1195692 El Torito img blks : 1 18 El Torito img opts : 1 grub2-boot-info El Torito img blks : 2 5088 (The estimation and load size of the UEFI image matches: 4 * 5088 = 20352) A prolific image hider is FreeBSD, e.g. FreeBSD-12.0-RELEASE-amd64-bootonly.iso : El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x0000 0x00 4 420 El Torito boot img : 2 UEFI y none 0x0000 0x00 1600 20 El Torito img blks : 1 1204 El Torito img blks : 2 400 (I suspect that 1204 * 2048 for the BIOS image is overestimated. But too long is better than too short when you want to repack the ISO.) End of anecdote. ------------------------------------------------------------------------ > There was no need to throw a 1 in there, outside of trying to appease people > who were already abusing the specs. Well, probably some participants in the standardization process were for size 0 and others for size 1. So they made a compromise. > 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 So your read loop needs to recognize byte 0 with values 0x01, 0x90, 0x91 in the 32-byte catalog records. If found, the next byte tells the platform id for the next boot image catalog records with byte 0 value 0x88. This platform id stays in effect until a new platform id is encountered. Do not assume that each section of the catalog has only one boot image entry. The specs allow more than one. > 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. No need to hurry. Consider my proposals with boot info table for platform id 0x00 with size 4, and with FAT filesystem size for platform id 0xef with size < 2 or larger 65532. I think they would largely improve the quality of the pseudo files. Have a nice day :) Thomas
