Re: [edk2-devel] EfiRom vs. iPXE usability note

["Michael Brown" <mcb30@ipxe.org>]

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