Reproducibility issue due to use of uname

Reproducibility issue due to use of uname

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

It looks like u-boot 2022.07-rc1 introduced a reproducibility issue that
is dependent on the running kernel.

I believe the commit that triggered this issue is:

  f7691a6d736bec7915c227ac14076f9993a27367 sandbox: allow cross-compiling sandbox

While the use of uname in the Makefile goes back well before this
commit, previously it had no apparent effect on the builds...

When building natively (e.g. CROSS_COMPILE is not set) with a 32-bit
userland toolchain, but running a 64-bit kernel, 32-bit arm targets end up
with BOOTAA64.EFI embedded in the binaries:

  https://tests.reproducible-builds.org/debian/rb-pkg/experimental/armhf/diffoscope-results/u-boot.html

  /EFI/BOOT/BOOTARM.EFI
  vs.
  /EFI/BOOT/BOOTAA64.EFI


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Reproducibility issue due to use of uname

[Heinrich Schuchardt]

On 6/9/22 18:06, Vagrant Cascadian wrote:
> It looks like u-boot 2022.07-rc1 introduced a reproducibility issue that
> is dependent on the running kernel.
>
> I believe the commit that triggered this issue is:
>
>    f7691a6d736bec7915c227ac14076f9993a27367 sandbox: allow cross-compiling sandbox

Thanks for reporting the issue.

Said patch does not change the value of MK_ARCH for CROSS_COMPILE="".
So this is not the relevant patch.

>
> While the use of uname in the Makefile goes back well before this
> commit, previously it had no apparent effect on the builds...
>
> When building natively (e.g. CROSS_COMPILE is not set) with a 32-bit
> userland toolchain, but running a 64-bit kernel, 32-bit arm targets end up
> with BOOTAA64.EFI embedded in the binaries:
>
>    https://tests.reproducible-builds.org/debian/rb-pkg/experimental/armhf/diffoscope-results/u-boot.html

The EFI boot manager can boot according to boot options define as UEFI
variables BOOTxxxx. We recently introduced support for booting via these
variables if they only point to a block device without a filename. In
this case we need to provide the name of the EFI binary. Only for the
sandbox this should depend on host architecture.

I need to correct include/efi_default_filename.h to only use variable
HOST_ARCH for the sandbox.

Best regards

Heinrich

>
>    /EFI/BOOT/BOOTARM.EFI
>    vs.
>    /EFI/BOOT/BOOTAA64.EFI
>
>
> live well,
>    vagrant