Comment 6 for bug 874373

Currently fwts runs dmidecode and parses the output for strings like <OUT OF SPEC> and <BAD INDEX>

For example, for the hardware being tested we get the following dmidecode output that triggers fwts to complain:

Handle 0x0027, DMI type 32, 20 bytes
System Boot Information
 Status: <OUT OF SPEC>

This is useless on many levels. I've completely re-written the dmi_decode test in fwts so it won't use dmidecode anymore. Instead it locates the SMBIOS header and uses this to find and then parses the numerous SMBIOS DMI entries. I've trimmed this down to now look at a subset of fields and these are checked against the SMBIOS specification to see if the field values comply with the latest version of the specification found at: http://www.dmtf.org/standards/smbios - currently the latest version is: http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_2.7.1.pdf

An example output now from fwts is:

00054 dmi_decode FAILED [HIGH] DMIValueOutOfRange: Test 1, Out of range
00055 dmi_decode value 0x0c (range allowed 0x00..0x08, 0x80..0xff) while
00056 dmi_decode accessing entry 'System Boot Information (Type 32)' @
00057 dmi_decode 0x000dc3a7, field 'Boot Status', offset 0x0a
00058 dmi_decode
00059 dmi_decode ADVICE: It may be worth checking against section 7.33 of
00060 dmi_decode the System Management BIOS (SMBIOS) Reference
00061 dmi_decode Specification (see http://www.dmtf.org/standards/smbios).
00062 dmi_decode

So, now I have more smarts in fwts. It can tell us what is out of range, what the allowed values are, the DMI table name and type and the field that is non-compliant. It will even guide the engineer to the relevant SMBIOS specification section. Quite frankly I cannot correlate 1800+ pages of a specification against every bit setting in the DMI tables and kernel usage of these settings to make a fwts smart enough to tell is if the deviation from the specification is going to cause us problems or not.

So fwts cannot currently make a fine value judgement to tell is if the non-compliant values are show-stoppers or annoyingly wrong BIOS data that may/may not cause system misbehaviour.

For BIOS testing, the role of this test is to flag up firmware that does not conform to the spec so engineers can take further action. If need be, we can re-visit this and add more intelligence, but realistically we are looking at *thousands* of individual settings to make a value-judgement upon.

Hope this helps.

The new dmi_decode test is now committed, commit 8c32d19fe2d558103093288c768da6210df709f1 and will appear in version V0.24.08 in the -devel PPA in the next day or so.