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.
Pretty sure that the shrink-wrap license issue was already tested in court and lost--completely unenforceable.
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.
"Many computer users don't allow outside or unprivileged users to run on their CPUs"
Your browser is running some outside unprivileged JavaScript for almost every page you visit. One of the exploits was specifically described for JavaScript running in a browser.
You don't even need to be able to execute code. Even code that would traditionally be considered harmless could potentially be used for side channel attacks if you e.g. control the input data. That invoice your ISP sent you as a PDF could potentially use a harmless piece of code inside Adobe Reader to do something harmful.
The fact that it has not been demonstrated yet does not mean it can't be done.
>_ 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.
The license also mentions NDA's and Pre-Release agreements
Looks like license they would include with pre-release/beta software.
7. CONFIDENTIALITY. The terms and conditions of this Agreement, exchanged
confidential information, as well as the Software are subject to the terms and
conditions of the Non-Disclosure Agreement(s) or Intel Pre-Release Loan
Agreement(s) (referred to herein collectively or individually as "NDA") entered
into by and in force between Intel and You, and in any case no less
confidentiality protection than You apply to Your information of similar
sensitivity. If You would like to have a contractor perform work on Your behalf
that requires any access to or use of Software, You must obtain a written
confidentiality agreement from the contractor which contains terms and
conditions with respect to access to or use of Software no less restrictive
than those set forth in this Agreement, excluding any distribution rights and
use for any other purpose, and You will remain fully liable to Intel for the
actions and inactions of those contractors. You may not use Intel's name in any
publications, advertisements, or other announcements without Intel's prior
written consent.
i think its actually illegal to sell consumer products with such strings attached, in most countries anyways.
intel is opening itself for a lawsuit here
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....