Slashdot Mirror
Intel Blocked Collaboration On Spectre/Meltdown Fixes, Says Linux Kernel Developer (eweek.com)
This week in Vancouver, Linux kernel developer Greg Kroah-Hartman criticized Intel's slow initial response to the Spectre and Meltdown bugs in a talk at the Open Source Summit North America. An anonymous reader quotes eWeek:
Kroah-Hartman said that when Intel finally decided to tell Linux developers, the disclosure was siloed.... "Intel siloed SUSE, they siloed Red Hat, they siloed Canonical. They never told Oracle, and they wouldn't let us talk to each other." For an initial set of vulnerabilities, Kroah-Hartman said the different Linux vendors typically work together. However, in this case they ended up working on their own, and each came up with different solutions. "It really wasn't working, and a number of us kernel developers yelled at [Intel] and pleaded, and we finally got them to allow us to talk to each other the last week of December [2017]," he said. "All of our Christmas vacations were ruined. This was not good. Intel really messed up on this," Kroah-Hartman said...
"The majority of the world runs Debian or they run their own kernel," Kroah-Hartman said. "Debian was not allowed to be part of the disclosure, so the majority of the world was caught with their pants down, and that's not good." To Intel's credit, Kroah-Hartman said that after Linux kernel developers complained loudly to the company in December 2017 and into January 2018, it fixed its disclosure process for future Meltdown- and Spectre-related vulnerabilities... "Intel has gotten better at this," he said.
An interesting side effect of the Meltdown and Spectre vulnerabilities is that Linux and Windows developers are now working together, since both operating systems face similar risks from the CPU vulnerabilities. "Windows and Linux kernel developers now have this wonderful back channel. We're talking to each other and we're fixing bugs for each other," Kroah-Hartman said. "We are working well together. We have always wanted that."
"The majority of the world runs Debian or they run their own kernel," Kroah-Hartman said. "Debian was not allowed to be part of the disclosure, so the majority of the world was caught with their pants down, and that's not good." To Intel's credit, Kroah-Hartman said that after Linux kernel developers complained loudly to the company in December 2017 and into January 2018, it fixed its disclosure process for future Meltdown- and Spectre-related vulnerabilities... "Intel has gotten better at this," he said.
An interesting side effect of the Meltdown and Spectre vulnerabilities is that Linux and Windows developers are now working together, since both operating systems face similar risks from the CPU vulnerabilities. "Windows and Linux kernel developers now have this wonderful back channel. We're talking to each other and we're fixing bugs for each other," Kroah-Hartman said. "We are working well together. We have always wanted that."
To me, there appears to be very little, if anything, to Intel's credit in this whole CPU disaster. Performance instead of security. What a mess. How long will it be before there's an Intel CPU that is not inherently insecure? Will a whole new architecture need to be designed?
This week in Vancouver, Linux kernel developer Greg Kroah-Hartman criticized Intel's slow initial response to the Spectre and Meltdown bugs in a talk at the Open Source Summit North America. An anonymous reader quotes eWeek:
Be careful there, Intel is so inept they will likely mistake you calling them slow with calling their CPUs slow, and they will send their lawyers after you with claims of illegal benchmarks.
Jokes aside, never EVER sign an NDA with Intel. Tell them to get fucked, and go talking about them anyway.
You should also consider exempting them from any responsible security disclosures. We have.
Everything gets published immediately without waiting on a reply from Intel, and in fact we won't even bother informing Intel, they can find out about their bugs and exploits the same as everyone else, not that they care.
At this point they also have fully used up their allotment of "one more chances"
We're holding the stance that its a license violation to use their fixed firmware. Not our problem they changed their minds, we have it in writing how that isn't true.
Let them sue and explain to the judge how their products are intentionally by design exploitable and costing lives. Let them explain why this is being enforced by contract for the 24 hours the legal documentation Intel published to the world and why they didn't at their own expense hand deliver the corrections that don't legally apply to us.
Zero tolerance has begun, have fun throwing your money down the legal department drain Intel.
Go ahead and sue us for pirating your shit far and wide and breaking all contracts with you due to your term violations.
More likely to cost Intel, if anyone. How I'm supposed to buy Intel hw if it is poorly supported by the Linux OS I need to use in my servers?
Intel can fix the specific Spectre-class vulnerabilities that have recently received a lot of attention, with some impact on performance. AMD wasn't vulnerable, and Intel can do something similar to what AMD did.
On the other hand, if you want to speak more broadly about issues like Meltdown and the various types of Spectre, AMD does have some vulnerabilities and is likely that EVERY high-performance CPU in the next five to ten years will have similar issues. Not precisely the same, but in the same general category. Simple, low-performance ARM chips can be used for security-sensitive operations.
Software is written as if it executes step-by-step, using a simple model of a CPU. Simple code looks like this:
if (userid larger than 1000) {
basekarma = 10;
}
In this simple model, the basekarma variable is never changed for the oldest users. In the simple model, a Pentium and Core i7 look the same. In the real world, a modern processor doesn't run things step-by-step, it runs multiple things at once. Since the userid is almost always greater than 1000, it DOES run the code in the IF statement every time, then reverses it in the rare instance that userid is 1000 or lower. That's faster than waiting for the userid check, because it can simultaneously set the variable and check the userid in one clock tick.
In the model, setting the basekarma can never have any effect on the userid. In the real world, basekarma isn't an idea, it's a set of silicon transistors with certain electrical charges. Those tiny transistors are only a few nanometers from the ones used for basekarma, and using them creates hear which heats up all the surrounding transistors (variables). Electrical charges in one, alternating a billion times per second, can and will effect the electrical charges of others that are just 100 nanometers away.
With the complexity of a modern CPU, it's not going to match the simplistic model. It's going to run multiple threads concurrently. Physical effects mean doing something to one set of memory locations can physically effect others (if only by forcing the system to slow down to avoid overheating).
Caches speed up operations by an order of magnitude when essentially the same thing is done over and over, such as handling each pixel or each sample of audio. Being faster means attackers can tell what is in the cache. Eliminating cache timing-based attacks would make the CPU MUCH slower.
A simple single- thread CPU without any speculative execution, only in-order execution, no cache or only very simple cache, and half a dozen other types of complexity could fairly well match the simple model used for programming, and therefore be pretty secure.
Overall, the security of a system is inverse to its complexity. Complex systems have many complex parts that hackers can manipulate. They'll never be secure, or at least not any time soon.
There have indeed been times when Intel acted in ways that benefited the Linux community. Of course, they also benefitted Intel.
OTOH, have you ever heard the term "Wintel"? They've acted detrimentally about as much as they've acted beneficially, and arguably more. They've designed systems that intentionally shut Linux out of application. They've refused to publish interface specs that they shared with a different OS vendor. Etc.
The problem with trying to assign a position to the company is that it's not an individual. Different groups have adopted different policies. If they were a person they'd be described as being MPD to an extreme degree, and in need of hospitalization. I find them untrustworthy, and when one of the legal or marketing personalities is in charge, totally untrustworthy. But they aren't the worst company that one must deal with.
I think we've pushed this "anyone can grow up to be president" thing too far.
But still no Be after 20 years? FAIL.
Il n'y a pas de Planet B.
Nah, Windows has the WSL. They decided it was truly time for the year of the LINUX desktop...brought to you by your good friends at Microsoft.
Donald Trump, on a crusade to make Nixon look respectable
Intel still ignores OpenBSD.
Ok, so Intel landed on the shady side of the performance/security tradeoff. That probably kept CPU prices artificially high for you for a while because it helped their market position. But don't worry, soon you will be allowed to give them more money for new processors which are less vulnerable. I'm sure this is the right incentive to never let something like this happen again.
Also, how should they know their CPUs have so many problems? NOBODY knew, apart from some geeks who write papers nobody understands. Especially this one CS professor (U.S. based, security focus) who tweeted a slide from a talk he gave years ago at an Intel event. Warned about all this out-of-order and speculative branching stuff, who was that again? I'm sure they are all just crazy conspiracy theorists. The government should really do something about them.
There have indeed been times when Intel acted in ways that benefited the Linux community.
When was that? Every time Intel does Linux development, they tie it to their own processors. They killed Meego by turning it into Moblin, which was slightly about making a new OpenGLES-based interface and mostly about making it Intel-specific (wouldn't even boot on AMD systems.)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
And being labeled a Troll for telling the truth is certainly going to encourage him to contribute in the future.
Is there any out-of-order with speculative execution architecture family out there that doesn't have these problems? IBM's z/Architecture?? No idea, and it's been a long since anyone bought an IBM mainframe for CPU power, but the modern out-of-order design was first developed for the System/360's supercomputer FPUs. Per my reading Wikipedia just now, of the non-dead ones, there were out-of-order MIPS and SPARC microarchitectures in the past. The big and successful ones today all suffer, Intel/AMD, ARM and IBM POWER.
I haven't seen the slightest bit of evidence that Intel "licenced" this sort of technology to anyone by AMD by definition, and the basic technology goes back to the 1960s and IBM, when it FRAND licensed all its patents due to a 1940s or very early 50s lawsuit settlement, that's one of the reasons their mag tape and mechanism designs became ubiquitous, as you can see in old movies. Of course by 1993-5 with others started doing out-of-order and at least in Intel's case speculative execution based on that IBM's patents had lapsed.
Thus we see of the few still successful high performance CPU makers all but AMD created Meltdown vulnerable designs, and all including Spectre vulnerable ones.
Seriously, this obsession has me asking "Show us on the doll when Intel touched you."
To Jefrey Dahmer's credit, he stopped killing and eating people after he was caught, convicted and imprisoned.
That's weird, since Microsoft invented the Blue Screen of Death.
Only in a very technical sense, Commodore for example did it a decade earlier in red for the Amiga. Here's a Wikipedia page on things like it.
*pacefalm*