Credit: By Sundry Photography/Shutterstock
An article this week by well-known computer programmer Bruce Perens shined a light on new restrictions Intel has placed on benchmarking the new microcodes designed to combat the L1 Terminal Fault. The report has brought on complaints among the enthusiast community, forcing Intel to respond.
We downloaded the microcode for ourselves and found the controversial text in the license file:
Unless expressly permitted under the Agreement, You will not, and will not allow any third party to (i) use, copy, distribute, sell or offer to sell the Software or associated documentation; (iii) use or make the Software available for the use or benefit of third parties; or (iv) use the Software on Your products other than those that include the Intel hardware product(s), platform(s), or software identified in the Software; or (v) publish or provide any Software benchmark or comparison test results.
Intel responded to our queries, stating:
We are updating the license now to address this and will have a new version available soon. As an active member of the open source community, we continue to welcome all feedback.
The Spectre/Meltdown vulnerabilities have whipped the semiconductor industry into a frenzy as processor vendors race to create patches to secure their chips, but new variations of the same vulnerabilities are popping up at a rapid pace. Intel processors, like chips from other vendors, have suffered significant overhead from the patches. The penalties vary based on workload but can reach as high as 10 percent on newer hardware. Older hardware can take a larger hit.
Intel's latest round of microcode patches addresses the L1 Terminal Fault. The company has already posted its performance measurements with its new patches in the Windows operating system. Intel's results show little performance impact in many scenarios, but up to a 31 percent performance loss in some virtual environments that house untrusted guest operating systems.
It's troubling, then, that Intel prohibited Linux vendors from sharing their findings. As with any set of vendor-provided benchmarks, enthusiasts like to see third-party results to suss out any inconsistencies. Intel could have been concerned that benchmarkers wouldn't follow testing best practices and thus share inaccurate test results. As an aside, such restrictions are very common in the enterprise, with vendors such as Dell/EMC, NetApp, VMware, and many many others, preventing users from publicly posting benchmarks of any of their servers, operating systems, or storage devices.
Another troubling angle came from Intel's restriction that seemingly prevented distributing the microcodes. Debian developers have complained publicly that its supporting packages are ready and have been for several weeks, but the company can't distribute them due to the new restrictions. Meanwhile, other Linux players, like Red Hat and SUSE, are busy distributing their patches regardless of the new licensing terms. This may just be a case of a single group having a philosophical complaint about the licensing terms, which wouldn't be unheard of from open source supporters.
In either case, the vulnerabilities have touched off a new wave of industry collaboration and openness. Aside from the early halting steps Intel made as the scope of the Spectre/Meltdown mess unfolded, the company has been forthcoming with information and made several public pledges to keep its customers informed. We hope the company continues in that spirit, and its willingness to change the microcode license is encouraging. We'll keep an eye out for the new revision of the licensing terms.