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.
"(v) publish or provide any Software benchmark or comparison test results. "
However, there is also a clause that says if you download the tgz you accept the license automatically. So, the act of downloading to read thatlicense means you have agreed will not publish benchmarks.
Orationem pulchram non habens, scribo ista linea in lingua Latina
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.
Well, the good lawyers call me when they do stuff like this. Or someone like me who can read a license and knows how a CPU is built. I have saved a few from mis-stating themselves.
Bruce Perens.
"In a time of universal deceit, telling the truth is a revolutionary act. George Orwell"
In a time of universal deceit, telling the truth is a total fracking waste of time.
Yes, I'm afraid it's come to this.
So Intel is saying if you want to benchmark to decide if you want to join the class action, you can't provide a detailed reason that you're joining the class? Lawsuits are a matter of public record - a judge is going to laugh at that kind of restriction. How does Intel expect it's going to enforce this?
Let's see a million people tweet their slowdown measurements and then it'll be Intel Legal's move. Somebody come up with the hashtag.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
No company can legally require a person this kind of performative obedience under any circumstance as a sold product like this.
Of course a company can enter into a contract with you that says you can't publish performance specs for their product. So I am going to assume that you mean to say that it's about a product they PREVIOUSLY sold you. The thing is, Intel did NOT previously sell you this microcode update.
The contract is that Intel will provide you this new microcode update, which is software, but that your license to use it will be restricted. (Specifically that you can't run this software on a computer for the purpose of benchmarking it, and that you won't publish such a benchmark.)
I don't see any legal problem with that contract.
It doesn't make Intel look good, but if you don't like the deal, then don't install the software.
Additionally, there have already been cases where judges have rendered TOS/EULA agreements as total bullshit and unenforceable.
If you cannot read the "By downloading, you agree..." license terms BEFORE downloading, then you have a shrink-wrap license problem. (By the way, shrink-wrap licenses are still upheld in some states such as Maryland and Virginia.) Even if there's a shrink-wrap issue, though, it is fairly obvious that INSTALLING the software after downloading and reading the accompanying license would constitute agreement to the terms.
Especially after a sale has already been completed, just look at the Sony Linux feature removal class action on the PS3 that cost them millions
That case was different than this. In the PS3 case, Sony removed access to their online gaming network, thereby crippling the box. Here, Intel is not removing access to anything: if you don't like the terms, then don't install the microcode update, and your computer will continue to function exactly as it did before, with all the same capabilities (and bugs) intact. Which is the point.
I expect the benchmarks will be out soon and all over the place, published in ways that make it impossible to figure out who to sue. Then, these benchmarks will be reported all over the place by people who never downloaded or installed or agreed to any of the license terms, and in fact did not perform any benchmarking themselves. Just published some results from some other shadowy people who cannot be sued.
Intel accused of age discrimination (May 28, 2018) Subtitle: "US federal investigators are looking into Intel's layoffs of 12,000 employees since 2016."
Judging from personal conversations with Intel employees and comments on web sites, Intel is badly managed:
Quote from thelayoff.com, Nov. 23, 2017:
"As a person who worked there several times as contract employee, which makes up most of the workforce. I have seen this happen many times, where older and higher paid blue badges get shown the door, and sometimes escorted out like criminals. This has created a paranoid environment among those who are left, so everyone starts back stabbing each other because they don't want to be the next one to be booted. And creates animosity to the contract workers who are treated like crap. So any workplace cohesion gets thrown out the window, because everyone is circling their prospective wagons."