On 02/19/21 21:12, Michael Brown wrote: > On 19/02/2021 17:33, Laszlo Ersek wrote: >> The PCI Firmware Spec does not seem to specify a particular "checksum >> byte" in the option ROM format, it only seems to state that the bytes in >> the option ROM must sum to zero. >> >> This (apparently) allows option ROM providers to implement different >> schemes for placing the checksum byte. >> >> When talking about traditional BIOS ROMs, EfiRom considers the last byte >> in the image the checksum byte. The assumption is that the last byte is >> padding anyway, so it can be repurposed as a checksum byte. >> >> On the other hand, iPXE's "util/catrom.pl", or more precisely, >> "util/Option/ROM.pm", considers byte#6 -- a reserved byte -- in the PCI >> Expansion ROM Header the checksum byte. >> >> iPXE's choice is arguably safer, because it does not assume any >> particular padding at the end of the traditional ROM BIOS image that >> could be stolen as checksum byte. > > Thank you for sharing this. It made me curious as to the reason why we > use that byte for the checksum. > > As far as I can tell, it dates back to at least the ISA-era Plug and > Play BIOS Specification v1.0a, which defines the option ROM header as > including a 4-byte "initialization vector" occupying bytes 3-6 > inclusive, with the comment: > > The field is four bytes wide even though most implementations may > adhere to the custom of defining a simple three byte NEAR JMP. > The definition of the fourth byte may be OEM specific. > > So, iPXE is safe to choose to use offset 6 as the checksum byte for any > iPXE ROM images, knowing that future specification versions could not > define an alternative use for this byte. > >> However, iPXE's "util/efirom" tool, which converts *.efidrv to *.efirom, >> doesn't seem to offer "EFI compression", while EfiRom does (-ec option). >> For QEMU live-migration compatibility, we further pad the *combined* ROM >> images, currently to 256 KB. Abandoning EFI compression would eat up >> approx. 80KB suddenly, and nearly exhaust our current padding. Hence the >> above "hybrid" approach, where we retain EfiRom for the EFI >> compression's sake, but use "util/catrom.pl" for combining the images. > > That part, at least, I can fix: > > https://github.com/ipxe/ipxe/pull/268 > > iPXE now produces compressed EFI ROM images by default. Thank you for > pushing me to do this!
:) I was 99% sure you'd just go ahead and implement it, in response to my email! :) Having browsed the iPXE commit history on-and-off for a while now, one gets the impression that such "events" are not "out of the ordinary" :) Thank you, Michael! Laszlo > >> Assuming my reading of the PCI Firmware Spec is correct, I think that >> not specifying a particular checksum byte, in the various headers, was a >> mistake in the spec. It's difficult to combine ROMs of different origins >> into a multi-ROM image, like this. > > I concur with this interpretation. As far as I can tell, there is no > general solution for updating the checksum that is guaranteed to work on > arbitrary BIOS ROM images. > > As the closest thing to the OEM for iPXE: please consider this email to > be the PnP "OEM specific" definition of the byte at offset 6 of the > expansion ROM header as being the checksum byte for any iPXE ROMs. Tools > working on _iPXE_ BIOS ROM images may update this byte as needed. > > Thanks, > > Michael > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#71939): https://edk2.groups.io/g/devel/message/71939 Mute This Topic: https://groups.io/mt/80761003/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
