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."
You know, he's not wrong. This is, in impact, way bigger than Intel's FDIV fiasco and that ended up in recalls.
That doesn't explain why FreeBSD wasn't notified until 5-6 months after Intel and ARM knew about the issue and until after Apple had shipped a patch. It also wasn't helped that there was no real coordination in releases. Apple shipped a binary update and there were patches in the Linux tree containing mitigation before the official end of the embargo period.
I am TheRaven on Soylent News
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 has been extremely worrying. What's more worrying are the number of 'security researchers' regurgitating Intel's bullshit verbatim. We have yet to fully see the fallout from this.
He's also dead right in that Intel has been mixing up the two issues, Meltdown and Spectre, deliberately, so they could tell everyone that it wasn't just Intel that was affected, and they also gave the impression that Spectre had been fixed when it was Meltdown that had been mitigated - with a patch that creates unacceptable performance problems, to a lesser or a greater extent.
Yes, all processor manufacturers are affected by Spectre, but it is Intel that is mostly affected because they implemented speculative loads badly without much attempt at segregation. They've also attempted to pass this off as 'historical architectural decisions we can do nothing about, but it is working as designed'.
>is hard to believe they ignored the risky aspects. I bet they were instructed to ignore the risk
The specific issue that Pentium line CPUs: a) do privilege check asynchronously; b) do it only for the "winning" execution branch was very well known among CPU design community.
Intel architects even bragged about that as their "innovation" in industry journals and filled a number of patents for that (this is the reason amd privilege checker runs on all branches)
Open Hardware doesn't fix problems in silicon that has already been manufactured. It might help with the next generation but it won't prevent bugs from appearing in the first place.
Bear in mind that the reason Open Source software works so well is that the marginal cost of (re)production is close to zero and that there are (comparatively) minimal capital costs. Really you just need a PC and a lot of time. Open Hardware is a worthy goal but it's going to be a LOT trickier to pull off in the real world for mostly economic reasons. Furthermore hardware isn't protected by copyright for the most part. It's protected by patents and those are expensive. Worse once someone has one on a piece of kit they can basically shut down any open hardware that uses that idea for the next 20 years.
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
No, it's not tricky to pull off.
If it wasn't tricky to pull off then it would have already been done on a wide scale. I'm not saying it's impossible but it is going to be a much tougher nut to crack than open software. Mostly for economic reasons rather than technical ones.
- Research and make use of expired patents extensively, file new ones defensively.
Who is going to do this? Who has the funding and more importantly the incentive to do this? IBM received 8000 patents in 2016 and numerous other tech companies received thousands more each. Exactly how do you plan to match that sort of pace? How do you plan to produce anything really useful without infringing on a pile of those patents? Not to mention fending off the flesh eating lawyers that give those patents teeth...
It's more capital intensive than software, but it's also not that expensive either.
I'm a certified accountant and an industrial engineer. I do cost accounting for a living. It is a LOT more expensive than software no matter how clever you are. There is a reason gross margins in manufacturing hardware are far thinner than in software. You don't escape these costs by just doing design either. Someone eventually has to make the product and that will require substantial capital. Then you have the cost of distributing the product. Unlike software which can be sent across the net for nearly free, hardware has to be shipped, stored and turned into products, all of which cost non trivial amounts of cash. If you think it isn't substantially more expensive than making and distributing software you haven't done the math.
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.
You are making a false equivalency here. Making and distributing software is COMPLETELY different than making and distributing hardware. The economics could not be more dissimilar. The legal protections (patents vs copyright) are different. The amount of up front capital required is different. You can modify software after it has been release but you cannot do that with (most) hardware. Basically just because it worked out well for software is does not mean it will work out well for hardware. Hope for the best of course but it's likely to be a difficult nut to crack.
Only a big corporate structure could support development of anything as complex as an OS.
Ultimately that turned out to be true. Basically all the developers of linux and most other major OSS projects are employed at large tech firms (and a few large foundations) and are paid to maintain them. It isn't a bunch of hobbyists in their garages.
Open hardware is harder, but probably not impossible.
Not impossible but for non-trivial applications it appears pretty close to it. The obstacles are predominately economic ones and some legal ones and they aren't minor obstacles. I'm not about to hold my breath for patent reform anytime soon and the patent swamp is a real problem. And the economics of making and distributing hardware are immutable. I think Open Hardware is a very worthy goal but it's going to be quite the challenge.