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

["Laszlo Ersek" <lersek@redhat.com>]

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
>