There really needs to be testing in FWTS to indicate when a manufacturer has put invalid or incorrect data in the DMI bits of their firmware.
For example:
DMI that reports strings like "O.E.M to fill in" or "TBD" or simply blank, or other strings that look incorrect.
Catching these is NOT an easy task, the test itself is fairly easy, just probe DMI and parse the items that should be parsed. But since the data is completely arbitrary, getting the strings right to match will probably be an ongoing process.
This would be VERY useful for both the client and server teams who do certification testing and could help identify pre-ship-level bios or other potential trouble spots.
Here is a recent example of two DMI types with bad data
Handle 0x0002, DMI type 2, 16 bytes
Base Board Information
Manufacturer: Type2 - Board Vendor Name1
Product Name: Type2 - Board Product Name1
Version: Type2 - Board Version
Serial Number: Type2 - Board Serial Number
Asset Tag: Type2 - Board Asset Tag
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: Type2 - Board Chassis Location
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0
Handle 0x0003, DMI type 3, 23 bytes
Chassis Information
Manufacturer: SeaMicro
Type: Tower
Lock: Not Present
Version: Chassis Version
Serial Number: Chassis Serial Number
Asset Tag: Chassis Asset Tag
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x00000000
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 0
SKU Number: Not Specified
Additionally, while the strings may well be arbitrary, they're likely common to BIOS vendors, so Phoenix would use the same generic strings, as would AMI, IBM, and whomever else creates firmware.