We have frequently covered the topic of supply chain problems related to reference code when silicon vendors ship vulnerable code to the entire ecosystem. These vulnerabilities typically require a significant amount of time and effort to get fixed since they impact all the vendors that incorporate the vulnerable code into the firmware on their devices.

The technology industry is in the midst of active discussions about the use of “software bill of materials” (SBOMs) to address supply chain security risks. In order to implement supply chain security practices, there must be better transparency on software dependencies. Previously, any piece of software shipped as black-box without providing any information related to software dependencies and third-party components. Firmware has largely been looked at the same way. In an earlier blog post, Binarly team discussed the multiple levels of complexity in the UEFI firmware ecosystem and supply chain taxonomy (The Firmware Supply-Chain Security Is Broken: Can We Fix It?).

Speculative execution mitigations have been discussed for some time, but most of the focus has been at the operating system level in order to adopt them in software stacks. What is happening at the firmware level? When it comes to applying these mitigations, how does the industry take advantage of them, and who coordinates their adoption specifically into the firmware? These are all good questions, but unfortunately no positive news can be shared.

A month ago, Binarly’s security research team managed the coordinated disclosure of 16 high impact vulnerabilities in HP devices and 23 additional security defects impacting major enterprise vendors. In less than a year, Binarly disclosed 42 high severity vulnerabilities haunting the UEFI firmware ecosystem, all serious enough to cause arbitrary code execution in System Management Mode (SMM).