Slashdot Mirror
Intel Publishes Microcode Security Patches With No Benchmarks Or Profiling Allowed (theregister.co.uk)
Long-time Slashdot reader Bruce Perens writes: The Register reports that Debian is rejecting a new Intel microcode update because of a new license term prohibiting the use of the CPU for benchmarks and profiling.
There is a new license term applied to the new microcode: "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; (ii) modify, adapt, enhance, disassemble, decompile, reverse engineer, change or create derivative works from the Software except and only to the extent as specifically required by mandatory applicable laws or any applicable third party license terms accompanying the Software; (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." UPDATE:: Intel has reworked the license to no longer prohibit benchmarking. Imad Sousou, corporate VP and general manager of Intel Open Source Technology Center, tweeted on Thursday: "We have simplified the Intel license to make it easier to distribute CPU microcode updates and posted the new version here. As an active member of the open source community, we continue to welcome all feedback and thank the community."
The security fixes are known to significantly slow down Intel processors, which won't just disappoint customers and reduce the public regard of Intel, it will probably lead to lawsuits (if it hasn't already). Suddenly having processors that are perhaps 5% to 10% slower, if they are to be secure, is a significant damage to many companies that run server farms or provide cloud services. I'm not blaming Intel for this, I don't know if Intel could have foreseen the problem. Since some similar exploits have been discovered for AMD and ARM CPUs, the answer could be "no." But certainly customers are upset.
Another issue is whether the customer should install the fix at all. Many computer users don't allow outside or unprivileged users to run on their CPUs the way a cloud or hosting company does. For them, these side-channel and timing attacks are mostly irrelevant, and the slowdown incurred by installing the fix is unnecessary.
So, lots of people are interested in the speed penalty incurred in the microcode fixes, and Intel has now attempted to gag anyone who would collect information for reporting about those penalties, through a restriction in their license. Bad move. The correct way to handle security problems is to own up to the damage, publish mitigations, and make it possible for your customers to get along. Hiding how they are damaged is unacceptable. Silencing free speech by those who would merely publish benchmarks? Bad business. Customers can't trust your components when you do that.
There is a new license term applied to the new microcode: "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; (ii) modify, adapt, enhance, disassemble, decompile, reverse engineer, change or create derivative works from the Software except and only to the extent as specifically required by mandatory applicable laws or any applicable third party license terms accompanying the Software; (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." UPDATE:: Intel has reworked the license to no longer prohibit benchmarking. Imad Sousou, corporate VP and general manager of Intel Open Source Technology Center, tweeted on Thursday: "We have simplified the Intel license to make it easier to distribute CPU microcode updates and posted the new version here. As an active member of the open source community, we continue to welcome all feedback and thank the community."
The security fixes are known to significantly slow down Intel processors, which won't just disappoint customers and reduce the public regard of Intel, it will probably lead to lawsuits (if it hasn't already). Suddenly having processors that are perhaps 5% to 10% slower, if they are to be secure, is a significant damage to many companies that run server farms or provide cloud services. I'm not blaming Intel for this, I don't know if Intel could have foreseen the problem. Since some similar exploits have been discovered for AMD and ARM CPUs, the answer could be "no." But certainly customers are upset.
Another issue is whether the customer should install the fix at all. Many computer users don't allow outside or unprivileged users to run on their CPUs the way a cloud or hosting company does. For them, these side-channel and timing attacks are mostly irrelevant, and the slowdown incurred by installing the fix is unnecessary.
So, lots of people are interested in the speed penalty incurred in the microcode fixes, and Intel has now attempted to gag anyone who would collect information for reporting about those penalties, through a restriction in their license. Bad move. The correct way to handle security problems is to own up to the damage, publish mitigations, and make it possible for your customers to get along. Hiding how they are damaged is unacceptable. Silencing free speech by those who would merely publish benchmarks? Bad business. Customers can't trust your components when you do that.
Actually no it doesn't. Of the 11 Spectre Variants AMD has only been vulnerable to about 3. And two of those variants were the ones that affected every out of order processor ever made.
The link at "a new license term" is to a license for a different product. I'm sure I didn't write that :-)
Bruce Perens.
The slashdot editor munged the link to the license text. It's here.
Bruce Perens.
Because they've never actually given me inside access to Slashdot. It's their playground. One or two editors look for things I've written, mostly the folks who work on the weekend.
I screw up as much as anyone else.
Bruce Perens.
Yes. I didn't write that link. The proper text can be found here.
Bruce Perens.
If you want a fully-open processor, there is Risc-V.
Bruce Perens.
Is it? Everything I've read lately is the ISA is free, but there are plenty of blobs for the other components that make an actual processor. It has the potential to be a truly free processor, but the early players don't have the resources for that.
I think POWER9 implementations are, right now, the closest. Raptor Computing Systems is shipping what looks to be real nice, but real EXPENSIVE, stuff. There may also be some OpenSPARC stuff.
Learning HOW to think is more important than learning WHAT to think.
>_ Inasmuch as I agree with "Just say no", it's not so simple.
See, I work for the government. We have to keep transparency in procurement. That is not an option; the public is our "boss". Hiding things is unacceptable.
Benchmarks are a necessary part of choosing a product.
And we must "publish or provide any Software benchmark or comparison test results", so that the procurement process is documented to be led impartially.
I have the law and a contract to choose which I will abide by.
Either I will violate the contract later or exclude Intel from bidding a priori.
You are too modest. You have been a huge asset to the community over many, many years. You are allowed the occasional error.
Phoronix seems to have disregarded that part and published some benchmarks anyway. https://www.phoronix.com/scan....