[ipxe-devel] BUILD_ID_CMD := perl -e 'printf "0x%08x", int ( rand ( 0xffffffff ) ); '

[Christian Nilsson]

On Sat, 19 Jan 2019 at 14:30, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 1/19/19 1:14 PM, Christian Nilsson wrote:
> >
> > This has already been discussed several times, and no-one has so far
> > provided an alternate fix for the need of this.
> > How would deleting temporary files fix the need for ROMs to see if
> > they are initializing the same or different instances of the ROM?
> > http://lists.ipxe.org/pipermail/ipxe-devel/2015-February/003978.html
> >
> > Another recent PR which eliminates the randomness but then creates the
> > issues that the randomness is needed for:
> > http://lists.ipxe.org/pipermail/ipxe-devel/2018-October/006323.html
> >
> > Commit that introduced this is
> > https://git.ipxe.org/ipxe.git/commitdiff/58f6e553625c90d928ddd54b8f31634a5b26f05e
> >
> Hello Christian,
>
> thanks for pointing me to those threads.
>
NP, since this has come up a few times I can understand if someone has
become tired of answering, so just trying to add and clarify with what
I know about it.

> These threads were about ROM targets. My interest is in the UEFI targets.
>
I'm reading those threads as wanting reproducible builds - The
relation to ROM is that ROM's need that "ident feature".

> I think for these we need neither a random build ID nor any build timestamp.
>
> So how about:
>
> diff --git a/src/Makefile.housekeeping b/src/Makefile.housekeeping
> index f8334921..492661f1 100644
> --- a/src/Makefile.housekeeping
> +++ b/src/Makefile.housekeeping
> @@ -1162,11 +1162,19 @@ blib : $(BLIB)
>  # Command to generate build ID.  Must be unique for each $(BIN)/%.tmp,
>  # even within the same build run.
>  #
> +ifeq ($(PLATFORM),efi)
> +BUILD_ID_CMD   := perl -e 'printf "0x00000000";'
> +else
>  BUILD_ID_CMD   := perl -e 'printf "0x%08x", int ( rand ( 0xffffffff ) );'
> +endif
>
>  # Build timestamp
>  #
> +ifeq ($(PLATFORM),efi)
> +BUILD_TIMESTAMP := 0
> +else
>  BUILD_TIMESTAMP := $(shell date +%s)
> +endif
>
>  # Build version
>  #
>
> I looked at:
>
> interface/efi/efi_driver.c:379: efi_driver_binding.Version = (
> build_timestamp >> 6 );
>
> I cannot see that using Version=0 would make any difference for the
> usability of snp.efi.
>
> Best regards
>
> Heinrich

Hopefully it would be safe to have the BUILD_ID_CMD as that for all
non rom builds (adding some comments for the logic maybe)
This would not give any id for .efirom builds, does not seem to be
used, so hopefully good anyway.

@Michael while Trying to understand this... how unique must a build be
for the rom and mrom cases?
In the feb 2015 thread you mention that they must be unique "even if
built from the same bin/blib.a"
Is it ok to flash the same .rom/.mrom build to multiple nics in the
same machine, and if so what needs to be taken into consideration for
them to be allowed to have the same build_id? (could we use checksums
from more sources to make this happen?)

In regards to BUILD_TIMESTAMP I might be wrong but I know that MS has
some weird requirements (or bugs) in regards to Version, I do however
not know which Version that was.
Would it be acceptable to default to last git commit date "git log -1
--format=%ct" and maybe have additional fallback if git fails (even
tho we really want to have the git commit id included in all builds,
especially those provided as binaries to users) ?

/Christian