Hi,
Many programs use SystemBiosDate registry key in order to verify the machine
they are running on (mostly for activation/licensing purposes).
This registry key is read only and is computed as explained before.
When this date changes - this may break the behavior of the machine.
This date never changes - unless used in virtual environments such as qemu.
This series help with:
* Ensuring this date never changes when smbios tables change
* Letting the user choose the date which will appear in the
SystemBiosDate registry key
Under QEMU.
Before this patch:
F-SEG contains the following dates: ['04/01/2014', '01/01/2011',
'06/23/99’]
F-SEG(0xfff5) contains '06/23/99’
Legacy SMBIOS Bios Date is '01/01/2011’
Non-Legacy SMBIOS Bios Date is '04/01/2014'
Running SeaBIOS on non-qemu machines gives:
F-SEG(0xfff5) contains '06/23/99’
Legacy SMBIOS is used and thus smbios type 0 returns
'01/01/2011’
Windows machines show SystemBiosDate of '04/01/2014’
* Notice how the SystemBiosDate has changed for non-qemu
machines to '04/01/2014’ once biostables.c was introduced (non legacy smbios)
Running SeaBIOS on qemu "-machine pc-i440fx-2.0” without
"smbios_type0.date” reporting machines gives:
F-SEG(0xfff5) contains '06/23/99’
Legacy SMBIOS is used and thus smbios type 0 returns
'01/01/2011’
Windows machines show SystemBiosDate of '04/01/2014’
* Notice how the SystemBiosDate has changed for qemu
pc-i440fx-2.0 machines to '04/01/2014’ once biostables.c was introduced (non
legacy smbios)
Same as running SeaBIOS on non-qemu machines.
Notice that if we do supply smbios_type0.date - if it is before
'04/01/2014’ - SystemBiosDate will not change - since it selects the last date
it encouters.
If it is after '04/01/2014’, it will change SystemBiosDate only
if smbios tables are allocated in FSEG - this depends on other smbios keys as
well (for the total length check) this is implemented in smbios.c
If it is after ’01/01/2080’ (not really interesting case), the
’06/23/99’ will be selected since MM/DD/80 is considered 1980 by SystemBiosDate.
Running SeaBIOS on on qemu "-machine pc-i440fx-2.1+” without
"smbios_type0.date” reporting machines gives:
F-SEG(0xfff5) contains '06/23/99’
Non-Legacy SMBIOS is used and thus smbios type 0 returns
'04/01/2014’
Windows machines show SystemBiosDate of '04/01/2014’
Same as running SeaBIOS on non-qemu machines.
Notice that if we do supply smbios_type0.date - if it is before
'04/01/2014’ - SystemBiosDate will not change - since it selects the last date
it encouters.
If it is after '04/01/2014’, it will change SystemBiosDate only
if smbios tables are allocated in FSEG - this depends on other smbios keys as
well (for the total length check) this is implemented in biostables.c
If it is after ’01/01/2080’ (not really interesting case), the
’06/23/99’ will be selected since MM/DD/80 is considered 1980 by SystemBiosDate.
If we want to control the value in SystemBiosDate controllable/stable for qemu
users - we must control all dates that appear in the FSEG section - which is
impossible today.
This helps fixing v2v migration scenarios and the editing of smbios tables.
It is true, like Kevin mentioned, that the current patch series might break
existing qemu/non-qemu machines, so a better v3 is required, maybe introduce
some new “/etc/win-systembiosdate” fw_cfg key, but I just wanted to explain
what made us make the changes in SeaBIOS.
The SystemBiosVersion change was made since the debug string "'Intel IGD BDSM
enabled at 0x%08x, size %lldMB, dev 00:02.0’” was seen in the same registry
path, fixing it is not expected to change guest behavior (SystemBiosVersion is
a REG_MULTI_SZ key and may contain multiple version strings and it is not
checked as the SystemBiosDate key which is REG_SZ) - so the changes for it can
be taken from the v2 series.
Sam
> On 23 May 2019, at 12:29, Gerd Hoffmann <kra...@redhat.com> wrote:
>
> Hi,
>
>>> The thing is, if the date reported by smbios tables is 05/02/2015 (which is
>>> bigger than 04/01/2014) so:
>>> If smbios tables are in fseg - Windows will select the most recent date -
>>> 05/02/2015
>>> If not - Windows will select the most recent date (the only one it found) -
>>> 04/01/2014
>>>
>>> So 'char win_bios_date[] VARFSEG = " 04/01/2014 “‘ will not help.
>>
>> Why would the smbios tables have a newer date? If you mean that qemu
>> is providing smbios table 0 and its date is newer,
>
> qemu doesn't provide table 0 (by default, possibly there is a obscure
> command line switch to change that), so seabios will generate it and the
> two dates should match.
>
> I kind of fail to see the problem the patch series tries to solve ...
>
> cheers,
> Gerd
>
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
