Slashdot Mirror
Intel Hit With Three Class-Action Lawsuits Over Meltdown and Spectre Bugs (theguardian.com)
An anonymous reader quotes a report from The Guardian: Intel has been hit with at least three class-action lawsuits over the major processor vulnerabilities revealed this week. Three separate class-action lawsuits have been filed by plaintiffs in California, Oregon and Indiana seeking compensation, with more expected. All three cite the security vulnerability and Intel's delay in public disclosure from when it was first notified by researchers of the flaws in June. Intel said in a statement it "can confirm it is aware of the class actions but as these proceedings are ongoing, it would be inappropriate to comment." The plaintiffs also cite the alleged computer slowdown that will be caused by the fixes needed to address the security concerns, which Intel disputes is a major factor. "Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time," Intel said in an earlier statement.
...while nobody's suing them for their Management Engine garbage. The two bugs may or may not be intentional, but the Intel Management Engine is absolutely intentional and cannot be disabled.
Of course nothing will ever come out of these lawsuits other than the lawyers getting richer.
If you just look at Intel's legal history, you'll see they have been mired in accusations and convictions of unethical and anti-competitive business practices since the early 1980s. Buying from Intel has always been a devil's bargain, it's just now that you are realizing what you have done because it's directly affecting you.
Anons need not reply. Questions end with a question mark.
As I understand it, it's not the cheating, it's sloppy cheating that's the problem. If they did a privilege check like AMD claims to then speculation in a user process couldn't lead to fetching kernel data into the cache. Zeroing the unnecessarily fetched data after speculation would mean it wasn't left sitting in the cache. Intel could have done either of these things, probably with no real performance penalty but they didn't think to.
If you want a CPU that doesn't 'cheat', go get yourself a 2011 Intel Atom. They run like ass. Have fun.
Actually, it's kind of in the middle. The problem isn't really that Intel tried to take a shortcut and boost performance with speculative execution, it's that they tried to take too big a shortcut and dropped some (all?) of the bounds checking as well. Since bounds checking provides security, and they must know this, they basically took a design decision to roll the dice with potential security flaws in exchange for a couple of extra perforance points and, potentially, a slightly simpler design.
The current approach is to do any bounds checking *after* the speculative execution in the event that the branch is to be executed, which is what enables the kernel memory to be leaked to userspace programmes. The secure way of doing it would be to do the bounds checking *during* the speculative execution, just as you would with normal execution, and in the event of a page fault fall back to the non-speculative execution approach. That would still be slightly slower, but not as bad as forcing the non-speculative execution approach every time, which is what the patches have now enforced.
It's a deliberate design decision, they should have known what the risks were, and there are a growing number of real world instances of applications showing repeatable ~30% performance hits directly attributable to the "fixes" (I've seen one myself firsthand that resulting in a public transport time tabling system failing). It might not work out so lucrative for an individual John Q. Public in a class action lawsuit, but it's starting to look quite likely that Intel is going to get reamed in the courts over this if they can't come up with a better workaround P.D.Q.
UNIX? They're not even circumcised! Savages!