[PATCH] smbios: Fix calculating BIOS Release Date

[Pali Rohár]

On Friday 23 April 2021 11:14:44 Pali Rohár wrote:
> 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?

I have looked and basically BIOS Release Date is used by operating
systems as a check that some bugs or functionality may be present.

So it really should be treated as "version" and not as "compile time" in
U-Boot. And I think same applies also for UEFI revision.