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.
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;
     }
 
_______________________________________________
vbox-dev mailing list
[email protected]
https://www.virtualbox.org/mailman/listinfo/vbox-dev

Reply via email to