On 23 May 2019, at 18:54, Kevin O'Connor <kevin@koconnor.net> wrote:

On Thu, May 23, 2019 at 04:11:21PM +0300, Sam Eiderman wrote:
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.

Okay, thanks.


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:
[...]

I understand.  If we ensured the smbios date is always in the
f-segment, would that also solve the problem?  (That is, using the
'char win_bios_date[] VARFSEG' method discussed previously.)

That would only be half of the solution, since F-SEG contains the following dates: ['04/01/2014', '01/01/2011', '06/23/99’]
It means that no matter what is found in "char win_bios_date[] VARFSEG”, SystemBiosDate will always be a date of ’04/01/2014’ or later.
To really control the output of SystemBiosDate, all dates in SeaBIOS’s F-SEG should be the desired SystemBiosDate (or older).

Sam


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.

Agreed, but I think using %pP is preferable.  I sent a corresponding
patch to the mailing list.

Took me a while to find the put_pci_device() implementation for %pP.
Looks great.


-Kevin