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 kraxel@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