From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web11.32761.1613989017376739278 for ; Mon, 22 Feb 2021 02:16:57 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=XNBPScNB; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613989016; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NEoImFWaXLl76zTtfKONUgnh1dsagrW50kJq2u4oly8=; b=XNBPScNBMHs3eTyn63wqE/gJxhKtU+q++MPGUBwyqmjFKgGfLlD4sO33GjKiBJUDy8cKy5 XUUG2VfknVaFeRC9t5NIu2GKcqxAYu3hp1XQMyiWsfnffJdGdpJLxcYyEDGIqH3xcitMSE WSvk+pCqovBh40S+enpiRxukWH9N5aI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-451-rMndvq9YM3CTqQnU2vN5Dg-1; Mon, 22 Feb 2021 05:16:53 -0500 X-MC-Unique: rMndvq9YM3CTqQnU2vN5Dg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 907168710EF; Mon, 22 Feb 2021 10:16:52 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-67.ams2.redhat.com [10.36.113.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id B622467882; Mon, 22 Feb 2021 10:16:51 +0000 (UTC) Subject: Re: [edk2-devel] EfiRom vs. iPXE usability note To: Michael Brown , devel@edk2.groups.io, iPXE devel list References: <940d8ccb-c493-0eff-2152-bc3e605389ab@ipxe.org> From: "Laszlo Ersek" Message-ID: Date: Mon, 22 Feb 2021 11:16:50 +0100 MIME-Version: 1.0 In-Reply-To: <940d8ccb-c493-0eff-2152-bc3e605389ab@ipxe.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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 >