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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/874373
Title:
dmi_decode test can have false positives when DMI info is out of spec
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fwts/+bug/874373/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
