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.
with these security patches installed, m'ladies
Making a bad situation, worse.
And the bigger question why is he not posting spam and dups like the rest of slashdot editors?
Only buy AMD.
Anons need not reply. Questions end with a question mark.
So Intel, as a condition of using your patch to fix the broken shit you sold us, you don't want us to use the patch to empirically determine just how broken your shit was, or else you'll sue us?
I've got the message loud and clear: you're crooked dirtbags.
I don't think I'll be sending any money your way in future.
The Machine stops.
Well kudos to Debian. I am very disappointed in seeing Red Hat, SUSE in saying the licence is fine.
Just goes to show you how close to Windows the big commercial Linux Distro are moving.
I hope that the part of Intel with some sense will wake up to what that other part of Intel is doing and fix this, quickly. When there is a company that big, it has a multiple personality disorder. Obviously this time somebody didn't think through the implications of their legal language.
Bruce Perens.
what I took away was "Go buy an AMD processor".
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Intel is AMAZINGLY self-destructive, IMO!
Intel says this: Intel's Brian Krzanich is forced out as CEO after 'consensual relationship' with employee. Another story: New details emerge on the office affair that led to Intel CEO Brian Krzanich's surprising resignation on Thursday.
Do you believe this quote? "The office affair which sparked Intel CEO Brian Krzanich's surprise resignation on Thursday started a decade ago and ended before he became CEO in 2013, The Wall Street Journal reported."
I'm guessing that Intel is trying to hide the real reasons that CEO Brian Krzanich is no longer CEO: 1) The Sceptre and Meltdown vulnerabilities in nearly all Intel CPUs, problems that began with former CEO Paul S. Otellini. 2) He used inside information to profit: Intel was aware of the chip vulnerability when its CEO sold off $24 million in company stock.
The new Intel CEO is Robert Swan. He joined Intel in September 2016 as CFO.
One of the most self-destructive acts is to appear to lie. Then everything else is examined as also possibly a lie.
Here's a link, I just hope Intel doesn't commandeer my#``{{#'+`$NO CARRIER
Since you cannot run the benchmark (in this case due to legal restrictions) just write FAIL* next to it. Then put the actual values for AMD, VIA and DMP CPUs. Once a few dozen articles get published where even DMP beats Intel's most expensive chips, they will wake up.
* FAIL means that the chip was unable to complete the benchmark due to faulty engineering or legal restrictions.