How to Build Products Using Open Platform Firmware

 

Platforms like MinnowBoard are a great starting point for IoT edge hardware... as long as you lock down a few things in the firmware.


Since these platforms are primarily made for debugging and hacking, they ship with unsigned binary firmware images and assume updates are run by a developer. The firmware typically ships with firmware debug features enabled, such as dumping UEFI PEI & DXE dispatch messages to the serial port. This is great for folks like me who develop firmware, but it's less than ideal for a commercial product.

Today firmware is more of a target for exploits, especially in IoT. The BIOS Protection Guidelines outlined in NIST 800-147 call for "digital signatures to ensure the authenticity of the BIOS update image" along with other measures to reduce exposure to firmware attacks. Fortunately the changes required to move a product from reference to production can be implemented on open hardware platforms, such as the MinnowBoard using an Intel® Atom™ processor. 

I've previously discussed the importance of signing firmware images for UEFI Capsule Update, but it's also critical to differentiate your project from it's open hardware parentage. Simple changes like disabling debug features, custom the platform GUID, and editing SMBIOS table data make your product look and feel like... well, your product.

For more info, check out slides from the "How to Build Products Using Open Platform Firmware" presentation I've given at ESC, Bsides, and Embedded World. These basic steps are important to understand whether you get platform firmware from open source or a commercial vendor. 

For more complete information about compiler optimizations, see our Optimization Notice.