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."
They've made an improvement on paper for future vulnerabilities to what they should have done all along. That would seem to fut under the category of 'very little.'
This is my signature. There are many like it, but this one is mine.
To me, there appears to be very little, if anything, to Intel's credit in this whole CPU disaster. Performance instead of security.
Given that, when the news came out, their first (and second, and third) thought was to put Marketing in charge of any response... that was to be expected.
#DeleteChrome
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.
But officially that won't happen next time. Believe it if you want to. Certainly it's proper to trust Intel's honesty and care for users.
I think we've pushed this "anyone can grow up to be president" thing too far.
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.