[vbox-dev] Updating _DMI_ needs updating _SM_

[Frank Mehnert]

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.
> 
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org
> https://www.virtualbox.org/mailman/listinfo/vbox-dev

-- 
Dr.-Ing. Frank Mehnert
Senior Manager Software Development Desktop Virtualization, VirtualBox
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt, Germany

Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20120402/2c984de7/attachment.sig>