[vbox-dev] Updating _DMI_ needs updating _SM_

[Jan Schunk]

Sorry for this misunderstanding, I think I understand now what you mean.
You are right, it gets neutralized, so only the 2nd checksum has to be 
fixed and the 1st will be also valid.


Frank Mehnert wrote:
> Jan,
>
> I would really appreciate if you could answer my question and if you
> could carefully read what I wrote. I did not deny that the two entries
> are part of the SMBIOS structure.
>
> Again: The 2nd checksum is for the 2nd part of the SMBIOS structure.
> If the 2nd part (offset 0x10 ... offset 0x1e) change and the 2nd checksum
> at offset 0x15 is adapted then the 1st checksum at offset 0x04 does NOT
> need to be adapted because adaption of the value at offset 0x15 neutralized
> the other changes within the 2nd part.
>
> The same applies for the BIOS checksum which is not part of the SMBIOS
> specification but would need to be adapted for the same reason. I might
> be wrong but if so then please tell me exactly _what_ I didn't get.
>
> So, please, to save us both from wasting more time: Which is the Windows
> tool which complained about a wrong checksum?
>
> Thanks,
>
> Frank
>
> On Monday 02 April 2012 18:06:56 Jan Schunk wrote:
>> Yes, the DMI Entry is part of the SM entry, as I also wrote (31 = 0x1f).
>> But the second checksum at 15h is only for the 15 Bytes (0x0f) stating
>> at 10h.
>> The entries we are talking about are part of SMBIOS specification, so
>> the values inside are described in the document.
>> There may be a BIOS checksum but not here.
>>
>> Frank Mehnert wrote:
>>> Of course there is a BIOS checksum but this is not mentioned in the
>>> SMBIOS specification because the SMBIOS is only a part of the normal
>>> system BIOS.
>>>
>>> Furthermore, as you can see in the source code, 'Entry Point Length'
>>> is 0x1f so it includes the following DMI table. Therefore the checksum
>>> at offset 04 includes also the DMI table.
>>>
>>> Which Windows tool did you use to check the SMBIOS checksum?
>>>
>>> Thanks,
>>>
>>> Frank
>>>
>>> On Monday 02 April 2012 17:10:52 Jan Schunk wrote:
>>>> Additionally I looked at the definition in the standards document.
>>>> There is no BIOS checksum in the structure. Both checksums are only
>>>> checksum of the EP itself.
>>>>
>>>> This means, other calculation has also to be changed:
>>>> -        for (unsigned i = 0; i<   pThis->cbPcBios; i++)
>>>>
>>>> +        for (unsigned i = VBOX_DMI_TABLE_OFFSET; i<
>>>> VBOX_DMI_TABLE_OFFSET + 0x10; i++)
>>>>
>>>>
>>>> http://www.dmtf.org/sites/default/files/standards/documents/DSP0134v2.5F
>>>> ina l.pdf
>>>>
>>>> 04h Entry Point Structure  BYTE
>>>> Checksum of the Entry Point Structure (EPS).
>>>> This value, when Checksum  added to all other bytes in the EPS,
>>>> will result in the value 00h (using 8-bit addition calculations).
>>>> Values in the EPS are summed starting at offset 00h, for Entry Point
>>>> Length bytes
>>>>
>>>> 15h Intermediate Checksum BYTE
>>>> Checksum of Intermediate Entry Point Structure (IEPS).
>>>> This value, when added to all other bytes in the IEPS,
>>>> will result in the value 00h (using 8-bit addition calculations).
>>>> Values in the IEPS are summed starting at offset 10h, for 0Fh bytes.
-------------- next part --------------
Index: VBox/Devices/PC/DevPcBios.cpp
===================================================================
--- VBox/Devices/PC/DevPcBios.cpp	(revision 40736)
+++ VBox/Devices/PC/DevPcBios.cpp	(working copy)
@@ -1272,9 +1272,9 @@
     {
         *(uint16_t*)&pThis->pu8PcBios[VBOX_DMI_TABLE_OFFSET + 0x06] = cbDmiTables;
         uint8_t u8Sum = 0;
-        for (unsigned i = 0; i < pThis->cbPcBios; i++)
-            if (i != VBOX_DMI_TABLE_OFFSET + 0x05)
-                u8Sum += pThis->pu8PcBios[i];
+        for (unsigned i = 0; i < 0x0f; i++)
+            if (i != 0x05)
+                u8Sum += pThis->pu8PcBios[VBOX_DMI_TABLE_OFFSET + i];
         pThis->pu8PcBios[VBOX_DMI_TABLE_OFFSET + 0x05] = -u8Sum;
     }