On Wed, May 22, 2019 at 04:49:35PM +0300, Sam Eiderman wrote:
On 20 May 2019, at 5:28, Kevin O'Connor kevin@koconnor.net wrote: On Fri, May 17, 2019 at 11:57:23PM +0300, Sam Eiderman wrote:
From: Liran Alon liran.alon@oracle.com
Windows kernel extracts various BIOS information at boot-time. The method it uses to extract SystemBiosDate is very hueristic. It is done by nt!CmpGetBiosDate().
nt!CmpGetBiosDate() works by scanning all BIOS memory from 0xF0000 to 0xFFFF5 (FSEG) in search for a string which is formatted like a date. It then chooses the string which represents the most recent date, and writes it to:
HKLM/HARDWARE/DESCRIPTION/System SystemBiosDate
This date should usually be BiosDate located at FSEG(0xFFF5).
FWIW, if you want to ensure a stable date is found, it's probably simpler to force a valid date string to be present in the f-segment. Something like: char win_bios_date[] VARFSEG = " 04/01/2014 ";
As with my previous emails, I'd recommend using a hard-coded date (not a build date) - as this tends to improve reproducibility.
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, then seabios could do something like:
memcpy(win_bios_date, s->bios_release_date_str, sizeof(win_bios_date));
Also, what problem occurs if sometimes 04/01/2014 is found and sometimes 05/02/2015 is found?
-Kevin