Slashdot Mirror
OpenBSD's De Raadt Pans 'Incredibly Bad' Disclsoure of Intel CPU Bug (itwire.com)
troublemaker_23 quotes ITWire:
Disclosure of the Meltdown and Spectre vulnerabilities, which affect mainly Intel CPUs, was handled "in an incredibly bad way" by both Intel and Google, the leader of the OpenBSD project Theo de Raadt claims. "Only Tier-1 companies received advance information, and that is not responsible disclosure -- it is selective disclosure," De Raadt told iTWire in response to queries. "Everyone below Tier-1 has just gotten screwed."
In the interview de Raadt also faults intel for moving too fast in an attempt to beat their competition. "There are papers about the risky side-effects of speculative loads -- people knew... Intel engineers attended the same conferences as other company engineers, and read the same papers about performance enhancing strategies -- so it is hard to believe they ignored the risky aspects. I bet they were instructed to ignore the risk."
He points out this will make it more difficult to develop kernel software, since "Suddenly the trickiest parts of a kernel need to do backflips to cope with problems deep in the micro-architecture." And he also complains that Intel "has been exceedingly clever to mix Meltdown (speculative loads) with a separate issue (Spectre). This is pulling the wool over the public's eyes..."
"It is a scandal, and I want repaired processors for free."
In the interview de Raadt also faults intel for moving too fast in an attempt to beat their competition. "There are papers about the risky side-effects of speculative loads -- people knew... Intel engineers attended the same conferences as other company engineers, and read the same papers about performance enhancing strategies -- so it is hard to believe they ignored the risky aspects. I bet they were instructed to ignore the risk."
He points out this will make it more difficult to develop kernel software, since "Suddenly the trickiest parts of a kernel need to do backflips to cope with problems deep in the micro-architecture." And he also complains that Intel "has been exceedingly clever to mix Meltdown (speculative loads) with a separate issue (Spectre). This is pulling the wool over the public's eyes..."
"It is a scandal, and I want repaired processors for free."
I disagree. Wider disclosure of a vulnerability means a greater chance that it's leaked to those who would exploit it for malicious purposes. There are lots of operating systems that run on the 32 and 64 bit AMD/Intel architecture. Should every single OS developer be notified of the vulnerability? Alternatively, notify those who have the largest user base, while trying to limit the disclosure. There is no perfect solution, but I favor limited disclosure. Frankly, OpenBSD just isn't that widely used, and if there were more users, they probably would have been notified ahead of the public disclosure.
Yes, Intel has tried to conflate Spectre and Meltdown to avoid negative PR. That is a legitimate criticism, but one that's not at all new. Otherwise, it's a lot of butthurt because OpenBSD just doesn't have that many users, and therefore wasn't notified.
Replaced/repaired, not free. Having said that the problem will be how to replace processors that have become obsolete and therefore out of the market, and where you can not simply replace all the associated hardware to pick up a current and patched processor. And I suspect that most of those who can change the associated hardware will simply migrate to AMD instead of taking another Intel.
Religion: The greatest weapon of mass destruction of all time
He's not wrong, both on the recall (which I'm not holding my breath on - I fully expect Intel to fight that to the bitter end given how much more painful than the Pentium replacements that would be for them) and the handling of the entire situation. There's clearly been a very high bar set betweeen those who were given the heads-up and those who were not, especially amongst service providers where it appears that only the *really* big players were in the loop. In the case of BSD devs specifically being left out of the loop though, perhaps Theo needs to take Linus' advice to Intel and a good hard look in the mirror as I seem to recall a similar incident not so long ago where the BSD devs were in the loop, but Theo refused to play ball and turned it into a free for all. I don't have the slightest problem with Theo standing up for his principles, but to do so without expecting there to be some rather obvious blowback should there be a similar situation in the future is rather naive, to say the least.
UNIX? They're not even circumcised! Savages!
Intel makes a monumental decision to benefit the short-term interest of their corporation at the long-term expense of their customers, then tries to weasel out of a equitable fix for their customers? It's not only their product that can't be trusted, it's their judgement at all levels. Heads need to roll at Intel for this....
Everything in the Universe sucks: It's the law!
"It is a scandal, and I want repaired processors for free."
And I want a pet unicorn. Come to think of it, unicorns are about as real a thing as a "repaired processor" since they physically cannot be repaired. He wants a replacement processor which almost certainly is never going to happen. Basically he's asking for every processor produced in the last 20 years to be replaced for free. If you think that's realistic I've got a bridge to sell you.
There will be plenty of legal action over this and the results of that will be the full extend of any compensation. Furthermore to get compensation he will have to show actual harm incurred. Simple fact is that at least so far there has been little to no tangible harm from this problem to date so standing will be an issue for anyone who sues. This might change in the coming months/years but until it does the chip makers aren't going to pay a dime to replace anyone's chip - flawed or otherwise.
"... I want repaired processors for free."
So do I. I want backdoor-free processors without payment. I will send Intel the faulty processors.
Intel CPU Backdoor Report (Jan. 1, 2018)
My opinion: Intel is a world-class company, with poor top-level management. Brian Krzanich is not the kind of person who is necessary. He is not a person with enthusiasm for technology combined with the social ability to lead a large company. One story about Krzanich: Intel CEO sold all the stock he could after Intel learned of security bug.
Paul Otellini, the previous CEO, was worse, in my opinion. Otellini "joined the finance department in 1974" I complained about Otellini 11 1/2 years ago in a Slashdot comment: More Intel employees should say in public what they have told me in private: Intel CEO Paul Otellini is not a competent leader. He lacks social ability. (June 09, 2006)"
Intel's health and strength is important to everyone on the planet, it seems to me. The technological part of the company can be excellent, but recent top management has not been able to handle the challenges.
The underlying issue, it seems to me, is that the process of choosing new CEOs tends to be defective. Perhaps all employees should have 50% of a vote, with the board of directors having 50%.
I dont care how much better their next CPUs might be, im jumping ship for AMD on my next upgrade. I did the same after NVidia fucked me over.
Of course, when Linux was new the argument was that an OS was just too big for a bunch of Free Software fans to manage. Only a big corporate structure could support development of anything as complex as an OS.
Open hardware is harder, but probably not impossible. It isn't a magic cure all, but it would tend to be free of corporate decisions like "we need 10% more performance, cheat here and nobody will notice" simply due to the open nature.
The patent swamp is a problem for that, but given how dependent the world is on secure digital hardware now, it's time to review the patent system. It may even become politically possible since it's to the point now where non-free hardware is hindering corporate profits.
This is a question of quality, not idealism and perverse incentives.
We aren't talking about IME here. You seem to be blindly assuming that Open hardware is always free of faults.
This is a question of quality. You seem to be blindly assuming that starts and ends with hardware faults. It does not, and it was the main point Theo was making here. Quality also has to do with how you handle faults when they happen.
And I'd sure as shit trust an open community a lot more than a proprietary closed one hell-bent on protecting profits at all costs. How many more bugs does Intel know about right now that they refuse to disclose because it might affect stock price? I rest my case.
Oh I agree 1000%. It's not a freebie, it's Intel living up to the implicit contract to provide a CPU with the performance it was benchmarked when I bought it and not allow user mode stuff to read kernel memory.
In the UK you could make an argument that a processor with that bug was 'not fit for purpose'. Of course it's in the US that a class action suit has the highest chance of success and outside the US Intel will probably follow the US lead.
It'll be interesting to watch. Then again all my Intel chips are soldered to laptop motherboards. And rather elderly laptops at that - it's not like I'm going to convince Intel to convince Asus and Apple to recall motherboards that are out of warranty and do BGA rework to replace the CPUs.
However if I had machines with socketed CPUs and I was in the US I'd join a class action suit. Mind you Intel will presumably claim KPTI and its equivalents on Windows and macOS fix the security problem and any change in performance doesn't violate any sort of contractual agreement. Which they may or may not get away with. I think they probably will.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
To quote Linus "A *competent* CPU engineer would fix this by making sure speculation doesn't happen across protection domains."
That's bullshit. When Intel introduced speculation across protection domains everyone including Linux was happy because it reduced system call costs. Without this, as soon as you get to a syscall / sysenter instruction, you stall the pipeline until all pending instructions have been committed. On a modern Intel CPU with close to 200 instructions in flight at a time, that's a measurable performance overhead.
We've known for a long time that side channels of this kind were possible, but not that they were performant. The new attacks are not interesting because they're side channels that allow data to be disclosed, they're interesting because they're side channels that allow disclosure far faster than previously believed. CPU designers believed that this kind of attack could only be exploited to get a bit every few seconds, at which rate it's not really worth trying as an attack and is pretty easy for software to spot (hmm, why is this thread at 100% and triggering insane numbers of cache misses? Looks malicious...). Now we know that you can use these attacks to get data at about 0.5MB/s, so you can scan the whole of memory in a few minutes.
I am TheRaven on Soylent News
I was one of those who called "no way" at first, but just yesterday I found this quote from an Intel engineer. It was originally posted in a reddit thread but has since been deleted - but not before being confirmed by other former engineers at Intel.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
And when Intel did this, everyone was happy that the cost of system calls went down. Now everyone is saying that they secretly knew that it was a security issue and only an idiot would have implemented it.
I am TheRaven on Soylent News
Some people are seeing >50% performance loss. Take a look at this graph: https://www.epicgames.com/fort...
Clearly they are going to need to spend some serious cash on upgrading their servers. The thread is full of players who can't connect.
Interestingly Intel's CPU data pages contain benchmarks. It will be interesting to see if they update them.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Was this attack known, and deemed an acceptable risk because of the incredible low rate at which data could supposedly be extracted?
Not this specific attack, but it was known that any source of nondeterminism in a processor was a source of side channels. These were largely ignored because these attacks get lots of papers at top security conferences but are really hard and slow to carry out in practice. Most of the existing attacks used the cache, but there are others involving things like the fact that computation on denormals is much slower than on normal floating point values (a fun one of these lets you scrape browser contents via WebGL and I don't believe has been mitigated yet in spite of being published a couple of years ago).
Speculative execution was known to be a potential source of these side channels for a while. Now that it's shown to be feasible, expect a lot more similar attacks.
I am TheRaven on Soylent News
I skimmed both papers, and that seems to about sum it up. Though I would add that all three attacks cause speculative execution of a construction like; "x = array[ *pointer ];", to push memory from an array into or out of cache based on the data loaded from the victim pointer. So combining the announcement does make some sense, as the details of any of those variants might point people to rediscovering the others.
I was impressed with the work put into variant 2. Tricking the CPU branch predictor into running ROP-like gadgets within a higher privileged process, then using cache access timing to work out what happened. It almost sounds like bad sci-fi dialog, yet they actually did it. And yes, the attack complexity sounds comparable to similar ROP stack smashing exploits.
Variant 2 is being patched in compilers. Both gcc and clang are working on patches (that might already be released?) that avoid any speculative execution of indirect branching. Using a trick documented by google to patch the stack with the destination address, and then return. So now we just have to recompile *everything* that has access to privileged / sensitive memory contents to hopefully prevent attackers doing anything useful with branch poisoning. Of course there will be a performance hit, as no indirect branches can be correctly predicted.
Personally I would say that the problem with variant 2 is sharing the branch predictor between domains. Branches taken in one process, influence how branches in other processes are predicted. I can understand that in a modern OS, multiple processes end up running the same library code, so this may have been a deliberate decision. But, if these tables were stored per-thread and context switched, this problem would probably have never been exploitable.
The Spectre paper did suggest that they had found some evidence of something like variant 2 on an AMD CPU. But I believe that the inner workings of AMD's branch predictor are not as easily deduced as Intel's. So the researchers took the easiest route and attacked 3 different Intel cores instead. That doesn't mean that nobody will ever work out how to pull off an attack though.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.