[PATCH] smbios: Fix calculating BIOS Release Date

[Pali Rohár]

On Friday 23 April 2021 11:04:26 Mark Kettenis wrote:
> > Date: Fri, 23 Apr 2021 10:27:16 +0200
> > From: Pali Rohár <pali at kernel.org>
> > 
> > On Friday 23 April 2021 10:25:21 Bin Meng wrote:
> > > Hi Pali,
> > > 
> > > On Fri, Apr 23, 2021 at 12:10 AM Pali Rohár <pali at kernel.org> wrote:
> > > >
> > > > BIOS Release Date must be in format mm/dd/yyyy and must be release date.
> > > > U-Boot currently sets BIOS Release Date from U_BOOT_DMI_DATE macro which is
> > > > generated from current build timestamp.
> > > >
> > > > Fix this issue by setting U_BOOT_DMI_DATE macro to U-Boot version which is
> > > > better approximation of U-Boot release date than current build timestamp.
> > > > Current U-Boot versioning is in format yyyy.mm so as a day choose 01.
> > > >
> > > > Some operating systems are using BIOS Release Date for detecting when was
> > > > SMBIOS table filled or if it could support some feature (e.g. BIOS from
> > > > 1990 cannot support features invented in 2000). So this change also ensures
> > > > that recompiling U-Boot from same sources but in different year does not
> > > > change behavior of some operating systems.
> > > >
> > > > Macro U_BOOT_DMI_DATE is not used in other file than lib/smbios.c
> > > > so remove it from global autogenerated files and also from Makefile.
> > > >
> > > > Signed-off-by: Pali Rohár <pali at kernel.org>
> > > > ---
> > > >  Makefile                |  2 --
> > > >  doc/develop/version.rst |  1 -
> > > >  lib/smbios.c            | 23 +++++++++++++++++++++++
> > > >  3 files changed, 23 insertions(+), 3 deletions(-)
> > > >
> > > 
> > > With this change the U-Boot date is only the release date, so one
> > > cannot tell exact BIOS date on which U-Boot was built from.
> > 
> > Hello Bin! I understood that this is expected and it should be the
> > release date, not the build date. But maybe it has different meanings in
> > different contexts?
> 
> To be honest, I think the BIOS data as advertised by SMBIOS is fairly
> useless for an open source firmware solution like U-Boot.  With
> multiple branches and forks in existence a single date doesn't really
> give you a good clue about what bugs might be present in the firmware
> or whether you are running the most up-to-date version.
> 
> Note that we already advertise the U-Boot release in the EFI firmware
> revision:
> 
> efi0 at mainbus0: UEFI 2.8
> efi0: Das U-Boot rev 0x20200700
> 
> so doing the same for SMBIOS doesn't really provide more information.
> Using the build date at least tells you how old the firmware is you're
> using...
> 
> I'm pretty sure traditional closed source firmware on x86 uses the
> build date here as well.

There is a difference, that this closed source firmware in most cases
cannot be recompiled therefore its "BIOS Release Date" is not changed
after "releasing" binary blob. So one version of this closed firmware
has only one BIOS Release Date.

But because U-Boot is distributed in source code and "BIOS Release Date"
is filled at compile time, it can be any value and therefore one U-Boot
version may have different values in "BIOS Release Date" section.

So... would not it be better to advertise stable (predictable) U-Boot
version as "BIOS Release Date" and "UEFI revision" instead of
unpredictable compilation timestamp?