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