Bug 1723702

(Not volunteering for this bug, just capturing the information we've exchanged previously, in a private thread.)

- Gerd points out that the RHEL8 ipxe combined oproms (for QEMU) contain IA32 EFI images as well, in addition to legacy BIOS and X64 EFI. Those IA32 EFI images are a waste, as we don't ship firmware with 32-bit DXE phase.

- In RHEL7, we only have BIOS and EFI X64, so I'd actually call this a regression in RHEL8, relative to RHEL7. It could be because we may have thrown away the RHEL7 packaging and re-forked RHEL8 from Fedora.

- I don't understand why the BIOS and X64 EFI images have grown like this. From RHEL7:

  Image 1 -- Offset 0x0
      Image size              0x10200
  Image 2 -- Offset 0x10200
      Image size              0x15A00

and from RHEL8 (skipping image#2, which is for IA32 EFI):

  Image 1 -- Offset 0x0
      Image size              0x12000
  Image 3 -- Offset 0x27A00
      Image size              0x18000

Unless we have explicitly enabled some new iPXE features in RHEL8, this growth looks unjustified (+7680 bytes for BIOS, +9728 bytes for X64 EFI).

... Does the iPXE build in RHEL8 pad binaries to 4KB, perhaps?

Looks like all files in usr/share/ipxe.efi from the qemu-rooms package have 262144 bytes.

So we're good.

Fixed-in: ipxe-20181214-2.git133f4c47.el8

Working on it Jeff. There's a problem with the build (test-name was wrong) and I can't use it.
I' running a new one.

Hi, Philippe Mathieu-Daudé

I tried the latest version "ipxe-roms-qemu-20181214-3.git133f4c47.el8.noarch",all files in /usr/share/ipxe.efi from the QEMU rooms packages have 262144 bytes.From my point of view,this bug has been fixed very well,so it can be moved to "VERIFIED". If my test method is wrong,please tell me a correct test method. thanks a lot.

# ls -l /usr/share/ipxe.efi/*
-rw-r--r--. 1 root root 262144 Aug 13 10:48 /usr/share/ipxe.efi/10222000.rom
-rw-r--r--. 1 root root 262144 Aug 13 10:48 /usr/share/ipxe.efi/10ec8029.rom
-rw-r--r--. 1 root root 262144 Aug 13 10:48 /usr/share/ipxe.efi/10ec8139.rom
-rw-r--r--. 1 root root 262144 Aug 13 10:48 /usr/share/ipxe.efi/15ad07b0.rom
-rw-r--r--. 1 root root 262144 Aug 13 10:48 /usr/share/ipxe.efi/1af41000.rom
-rw-r--r--. 1 root root 262144 Aug 13 10:48 /usr/share/ipxe.efi/8086100e.rom
-rw-r--r--. 1 root root 262144 Aug 13 10:48 /usr/share/ipxe.efi/808610d3.rom
-rw-r--r--. 1 root root 262144 Aug 13 10:48 /usr/share/ipxe.efi/80861209.rom

Thanks
LeiYang

Hi Lei, a more extensive test can be to change something in the iPXE code to make the binary bigger,
rebuild iPXE and verify that an error is generated because the resulting file is too big (more than 256KiB).

(In reply to Philippe Mathieu-Daudé from comment #11)
> Hi Lei, a more extensive test can be to change something in the iPXE code to
> make the binary bigger,
> rebuild iPXE and verify that an error is generated because the resulting
> file is too big (more than 256KiB).

Hi,Philippe

About the meaning of more extensive test and rebuild iPXE,I am not sure if the meaning I understand is what you mean .Can you tell me a specific test case?

Thanks a lot.
LeiYang.

(In reply to Lei Yang from comment #12)
> (In reply to Philippe Mathieu-Daudé from comment #11)
> > Hi Lei, a more extensive test can be to change something in the iPXE code to
> > make the binary bigger,
> > rebuild iPXE and verify that an error is generated because the resulting
> > file is too big (more than 256KiB).
> 
> Hi,Philippe
> 
> About the meaning of more extensive test and rebuild iPXE,I am not sure if
> the meaning I understand is what you mean .Can you tell me a specific test
> case?

The goal of this BZ is to catch if the resulting roms ever pass the 256KiB limit.

In the patch "Fail the build if the QEMU roms are bigger than 256KiB" there is an example of failure:

  $ rhpkg compile
  [...]
  + truncate -s '>256K' bin-combined/10222000.rom
  ++ stat -c %s bin-combined/10222000.rom
  + test 269472 -lt 262144
  error: Bad exit status from /var/tmp/rpm-tmp.BThs5p (%build)
  RPM build errors:
      Bad exit status from /var/tmp/rpm-tmp.BThs5p (%build)

This will be catch by the brew builders before reaching QA,
so using patch inspection to verify this BZ is probably enough.

(In reply to Philippe Mathieu-Daudé from comment #13)
> (In reply to Lei Yang from comment #12)
> > (In reply to Philippe Mathieu-Daudé from comment #11)
> > > Hi Lei, a more extensive test can be to change something in the iPXE code to
> > > make the binary bigger,
> > > rebuild iPXE and verify that an error is generated because the resulting
> > > file is too big (more than 256KiB).
> > 
> > Hi,Philippe
> > 
> > About the meaning of more extensive test and rebuild iPXE,I am not sure if
> > the meaning I understand is what you mean .Can you tell me a specific test
> > case?
> 
> The goal of this BZ is to catch if the resulting roms ever pass the 256KiB
> limit.
> 
> In the patch "Fail the build if the QEMU roms are bigger than 256KiB" there
> is an example of failure:
> 
>   $ rhpkg compile
>   [...]
>   + truncate -s '>256K' bin-combined/10222000.rom
>   ++ stat -c %s bin-combined/10222000.rom
>   + test 269472 -lt 262144
>   error: Bad exit status from /var/tmp/rpm-tmp.BThs5p (%build)
>   RPM build errors:
>       Bad exit status from /var/tmp/rpm-tmp.BThs5p (%build)
> 
> This will be catch by the brew builders before reaching QA,
> so using patch inspection to verify this BZ is probably enough.


Hi,Philippe

I can view the patch information about this bz through the brewweb changelog. Then download this fixed version of the source rpm and extract it.
# rpm2cpio ipxe-20181214-3.git133f4c47.el8.src.rpm|cpio -div
0001-build-customize-configuration.patch
0002-Use-spec-compliant-timeouts.patch
0003-Strip-802.1Q-VLAN-0-priority-tags.patch
ipxe-20181214-git133f4c47.tar.xz
ipxe-vlan-cmds.patch
ipxe.spec
5162 blocks

By review the file ipxe.spec content has changed as follows:
  make_ipxe CONFIG=qemu bin/${rom}.rom
  make_ipxe CONFIG=qemu bin-x86_64-efi/${rom}.efidrv
  vid="0x${rom%%????}"
  did="0x${rom#????}"
  EfiRom -f "$vid" -i "$did" --pci23 \
         -b  bin/${rom}.rom \
         -ec bin-x86_64-efi/${rom}.efidrv \
         -o  bin-combined/${rom}.rom
  EfiRom -d  bin-combined/${rom}.rom
  # truncate to at least 256KiB
  truncate -s \>256K bin-combined/${rom}.rom
  # verify rom fits in 256KiB
  test $(stat -c '%s' bin-combined/${rom}.rom) -le $((256 * 1024))

The file content has changed as same as patch posted. From my point of view, there should be no the bug now.

Best regards.
LeiYang

(In reply to Lei Yang from comment #14)
> By review the file ipxe.spec content has changed as follows:
>   make_ipxe CONFIG=qemu bin/${rom}.rom
>   make_ipxe CONFIG=qemu bin-x86_64-efi/${rom}.efidrv
>   vid="0x${rom%%????}"
>   did="0x${rom#????}"
>   EfiRom -f "$vid" -i "$did" --pci23 \
>          -b  bin/${rom}.rom \
>          -ec bin-x86_64-efi/${rom}.efidrv \
>          -o  bin-combined/${rom}.rom
>   EfiRom -d  bin-combined/${rom}.rom
>   # truncate to at least 256KiB
>   truncate -s \>256K bin-combined/${rom}.rom
>   # verify rom fits in 256KiB
>   test $(stat -c '%s' bin-combined/${rom}.rom) -le $((256 * 1024))
> 
> The file content has changed as same as patch posted. From my point of view,
> there should be no the bug now.

Exact. Thank you for verifying manually!

From my test, there is no the issue with latest ipxe package.So this bug has been fixed very well,move to "VERIFIED".

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3498