[ipxe-devel] [edk2-devel] EfiRom vs. iPXE usability note
Michael Brown
mcb30 at ipxe.org
Fri Feb 19 20:12:17 UTC 2021
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!
> 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
More information about the ipxe-devel
mailing list