Tweet
The August 2018 processor microcode update to address security issues has been provided here:
In the tar-ball is a license file which includes the following:
"3. LICENSE RESTRICTIONS. ... You will not, and will not allow any third party to ... (v) publish or provide
any Software benchmark or comparison test results."
Debian has a bug (#906158) which indicates this make it impossible for them to distribute the microcode as part of their distribution. That bug can be found here:
There is also an article explaining the issue here:
While the Intel VP/GM of Intel Open Source Technology Center should be the most sympathetic to the concerns of the Debian community, in the article he chooses instead to ignore the section 3 provision entirely. Imad Sousou of the Open Source arm of Intel decides instead of focus only on the redistribution grant provided by section 2 subsection iii. This stance seems to indicate he sees nothing wrong with the anti-benchmark clause as long as there is a section claiming redistribution is legal. As such, it seems to me it is unlikely Intel will be addressing these concerns and future microcode will continue to have the same restriction.
It is my feeling this could have an impact on Phoronix. Take as an example if Phoronix eventually provides an article detailing how the Phoronix Test Suite performs on a future Ubuntu 18.04.2. Also for the example, the test was run on the same Intel hardware which a previous article used the benchmark suite for Ubuntu 18.04.0 or 18.04.1. Even if the article never talks about the microcode update or directly compares the results with the previous article, it may be Intel would consider the newer version of Ubuntu's inclusion of the microcode update to make the article as a violation of the license terms for the microcode and seek legal action to get the article taken down.
The license also has no exception for benchmark created by Intel itself! There is a github repo of COSbench which can help benchmark such software as OpenStack Swift. If a microcode update impacts the performance of a OpenStack Swift cluster, the performance can usually be recovered by growing the number of nodes in the cluster and tuning the configuration. Using COSbench in an open discussion would be helpful in conveying what people needed to change in their environments to provide a rough guideline of what others should expect. However, posting results from Intel's COSbench in the context of microcode updates is prohibited by Intel's license and may be open to legal action by the Intel.
What upsets me the most is that Intel has made clear in how it has marketed it's Xeon family of processors that performance and security are key features of the product. To make accepting a prohibition on discussing the performance part of getting critical security updates goes against that marketing. If Intel feels the performance of it's past processors need to be kept secret then it should not be pushed as a key item provided by their products. If providing security fixes includes strong-arming customers to accept new terms which are not in the customer's own interest then they should not be pushing security as a key item provided by their products.
What Imad Sousou of Intel should understand that if a section someday appears stating that customer's must give their first born to Intel, the fact section 2 subsection iii still makes it legal to redistribute will never make that new criteria acceptable.
In the tar-ball is a license file which includes the following:
"3. LICENSE RESTRICTIONS. ... You will not, and will not allow any third party to ... (v) publish or provide
any Software benchmark or comparison test results."
Debian has a bug (#906158) which indicates this make it impossible for them to distribute the microcode as part of their distribution. That bug can be found here:
There is also an article explaining the issue here:
While the Intel VP/GM of Intel Open Source Technology Center should be the most sympathetic to the concerns of the Debian community, in the article he chooses instead to ignore the section 3 provision entirely. Imad Sousou of the Open Source arm of Intel decides instead of focus only on the redistribution grant provided by section 2 subsection iii. This stance seems to indicate he sees nothing wrong with the anti-benchmark clause as long as there is a section claiming redistribution is legal. As such, it seems to me it is unlikely Intel will be addressing these concerns and future microcode will continue to have the same restriction.
It is my feeling this could have an impact on Phoronix. Take as an example if Phoronix eventually provides an article detailing how the Phoronix Test Suite performs on a future Ubuntu 18.04.2. Also for the example, the test was run on the same Intel hardware which a previous article used the benchmark suite for Ubuntu 18.04.0 or 18.04.1. Even if the article never talks about the microcode update or directly compares the results with the previous article, it may be Intel would consider the newer version of Ubuntu's inclusion of the microcode update to make the article as a violation of the license terms for the microcode and seek legal action to get the article taken down.
The license also has no exception for benchmark created by Intel itself! There is a github repo of COSbench which can help benchmark such software as OpenStack Swift. If a microcode update impacts the performance of a OpenStack Swift cluster, the performance can usually be recovered by growing the number of nodes in the cluster and tuning the configuration. Using COSbench in an open discussion would be helpful in conveying what people needed to change in their environments to provide a rough guideline of what others should expect. However, posting results from Intel's COSbench in the context of microcode updates is prohibited by Intel's license and may be open to legal action by the Intel.
What upsets me the most is that Intel has made clear in how it has marketed it's Xeon family of processors that performance and security are key features of the product. To make accepting a prohibition on discussing the performance part of getting critical security updates goes against that marketing. If Intel feels the performance of it's past processors need to be kept secret then it should not be pushed as a key item provided by their products. If providing security fixes includes strong-arming customers to accept new terms which are not in the customer's own interest then they should not be pushing security as a key item provided by their products.
What Imad Sousou of Intel should understand that if a section someday appears stating that customer's must give their first born to Intel, the fact section 2 subsection iii still makes it legal to redistribute will never make that new criteria acceptable.
Comment