[HN Gopher] Downfall fallout lawsuit: Intel knew AVX chips were ...
___________________________________________________________________
Downfall fallout lawsuit: Intel knew AVX chips were insecure and
did nothing
Author : doener
Score : 75 points
Date : 2023-11-12 09:23 UTC (13 hours ago)
(HTM) web link (www.theregister.com)
(TXT) w3m dump (www.theregister.com)
| jruohonen wrote:
| "The complaint alleges that Intel has told customers since the
| release of its 9th generation CPUs in October 2018 that it
| implemented a hardware fix for the Spectre and Meltdown flaws and
| had mitigated those vulnerabilities on older processors. But the
| corporation, allegedly, knew its AVX instructions allowed a
| similar sort of attack."
| usr1106 wrote:
| Intel is nearly as criminal as Volkswagen was (and many car
| manufacturers that did the same, but were caught less visibly).
| The latter cheated with anti-pollution regulations, Intel with
| computer security. Maybe a slight difference is that car
| manufacturer with full intention violated regulations. Intel
| "only" neglected the knowledge their experts had that their
| products were insecure.
|
| In both cases they fully knowingly sold customers inferior,
| dangerous products without telling what they knew. Intel deserves
| to get massive fines and their managers deserve criminal charges
| as it has happened to the car industry.
| SubjectToChange wrote:
| Those two cases aren't comparable by any stretch of the
| imagination.
| zmgsabst wrote:
| Yes -- Volkswagen only cheated a standards test while Intel
| sold a defective product.
| SubjectToChange wrote:
| The Volkswagen scandal is beyond the pale. It is genuinely
| difficult to understate how catastrophic it was for the
| company. To this day ex-CEO Martin Winterkorn is wanted for
| charges in the United States.
|
| As for Intel it's difficult to judge without knowing how
| complicit they were. The fact it took years to for a proof
| of concept of Downfall to surface lends some credibility to
| their choices. Moreover equating a security vulnerability
| to being outright defective is overeager, to say the least.
| If that were true then you might as well sue the vendor of
| any lock that has been successfully picked, cut, shimmed,
| or broken.
| zmgsabst wrote:
| The difference between Intel and lock manufacturers is
| honesty.
|
| Lock manufacturers will tell you how resistant their
| products are to particular attacks, eg being drilled out.
|
| I wouldn't say Intel sold defective products if they were
| honest -- and said that speed ups came at the cost of
| chip level security. But they didn't.
|
| Do you believe that Intel would have sold as many chips
| if they'd been honest -- "our products are faster than
| before by trading your security for speed"?
| formerly_proven wrote:
| > Lock manufacturers will tell you how resistant their
| products are to particular attacks, eg being drilled out.
|
| Most padlocks you can buy in Home Depot can be trivially
| bypassed in at least one way (typically shimming, often
| also vulnerable to comb picking or reaching through the
| core); virtually all wafer locks are highly susceptible
| to raking and can literally be opened with a paperclip.
| These are akin to admin/admin credentials.
|
| Physical security is an absolute joke most of the time
| compared to software security.
| SubjectToChange wrote:
| _I wouldn't say Intel sold defective products if they
| were honest -- and said that speed ups came at the cost
| of chip level security. But they didn't._
|
| The trade off between risk and performance isn't a smooth
| gradient in this case. Eventually conservative behavior
| under a certain threshold does nothing but cost
| performance and waste power. Therefore, the multi-billion
| dollar question is where that threshold is and how
| closely can a design toe that line. Perhaps I am wrong,
| but I don't believe Intel's management would risk a
| vulnerability like Downfall for better SIMD benchmarks.
|
| _Do you believe that Intel would have sold as many chips
| if they'd been honest -- "our products are faster than
| before by trading your security for speed"?_
|
| Outside of the "prosumer" market, the vast majority of
| retail consumers do not even look at CPU benchmarks, nor
| could they understand them if they did. The true target
| of those performance numbers is the enterprise segment, a
| reoccurring multi-billion dollar revenue stream for
| Intel. With that in mind, it makes about as much sense
| for Intel to ignore vulnerabilities for benchmarks as it
| does for a milkman to sell spoiled milk.
| BlueTemplar wrote:
| A huge difference seems to be that in the diesel case the
| cheating was an open secret for decades, with even amateur
| journals describing how it worked a decade before the "scandal"
| blew out.
| SubjectToChange wrote:
| Over the past decade hardware complexity, and competitive
| pressure, has drastically increased. At the same time
| verification methodologies and tools have failed to keep pace.
| This can even be seen in the steady increase of errata in Intel's
| architecture manuals, and they are hardly alone in that respect.
| pgeorgi wrote:
| The problem is that Intel tries to "solve" security by adding
| new layers on top of the gargantuan mess of layers that already
| exists instead of reevaluating decisions made 30 years ago and
| dealing with compatibility issues through emulation.
| SubjectToChange wrote:
| What is this mess you are referring to? And what decisions
| made 30 years ago need to be reevaluated?
| treprinum wrote:
| Are we going to prosecute all long-tail problems in any product?
| Often it takes years or decades to unveil a problem and changing
| a chip design is multi-year task. So even if Intel knew AVX could
| lead to attacks, a timely fix might not have been possible.
| usr1106 wrote:
| A fix, no. But a warning to customers would have been a matter
| of days even with lawyers involved.
| beebeepka wrote:
| I fail to see how Intel deserves any benefit of the doubt after
| the speculative execution fiasco they engineered to make their
| CPUs faster.
|
| Why do people conveniently forget even fairly recent history is
| beyond me.
| treprinum wrote:
| Speculative execution was what made CPUs fast. That some
| creepy people use it for hacks is another story. Are we going
| to end up with super slow CPUs with super hard security in
| the end? As there is a trade-off between speed and security,
| so pick one or the other. I would rather have a fast CPU than
| one that prevents hacking in some narrow scenarios. Cloud
| operators might have another view, but why should I be
| punished for scenarios that won't ever happen on my laptop?
| tmtvl wrote:
| As someone who has used computers since the early '90s even
| if you take away speculative execution CPUs are still
| ridiculously fast. The problem is that people are doing
| very slow stuff on them (Python, Electron, layers upon
| layers of abstractions) and only getting away with it due
| to (sometimes) dangerous hacks.
|
| Let's look at a random processor, like, say, the Intel
| Pentium G3420. A budget CPU released in December 2013
| (coming up on its 10th birthday), it's a duo core CPU with
| a 3.2 GHz clock speed. Now I don't know what your usecase
| is, not many problems are nicely parallelizable, however at
| the scale we're talking it doesn't really matter that much.
| Because 3.2 billion instructions is a really big number.
| Now don't get me wrong, a million is also a quite sizable
| number; while 1 dollar won't even buy you a loaf of bread a
| million dollars will buy you a real fancy house, but a
| billion goes even beyond that. For example if you live to
| be 85 years old and from the moment you are born until the
| moment you pass away you do a thousand calculations per
| hour, every hour of the day, every day of every year, you
| will have done 750 million calculations. That's less than a
| quarter of what that ancient budget CPU does _per second_.
|
| Unfortunately some people, when given access to such power,
| have a tendency to abuse it. And that's what leads us to
| things like a chat app taking 9 seconds to launch.
| BlueTemplar wrote:
| Can't these security mitigations be disabled if you are
| willing to endure the increased security risk ?
|
| (Though an hardware switch would be better for these.)
| beebeepka wrote:
| It was only part of what made them fast and they should
| absolutely have told their clients what the price for that
| performance increase was. Choice is fine but it has to be a
| an informed one.
| TerrifiedMouse wrote:
| Every modern CPU by Intel's rivals have had speculative
| execution vulnerabilities too.
|
| The OG transient execution CPU vulnerability, Spectre, works
| on Intel, AMD, modern ARM-based, and IBM processors.
| joenathanone wrote:
| > Are we going to prosecute all long-tail problems in any
| product?
|
| Hopefully yes, if it's proven the vendor knew but released
| anyway or didn't disclose.
| imglorp wrote:
| Realistically, no. Security is not a feature people are dying
| to pay for, it's just overhead. Look at Experian, on the
| front page again, still insecure. It's cheaper to make the
| defective product and say you're a little sorry, now and
| then.
| badrabbit wrote:
| Their decision not to fix is not the problem, their
| decision to keep the flaw a secret and sell products with a
| performance expectation set and then release patches that
| slow down that paid for performance is.
| SubjectToChange wrote:
| mitigations=off
|
| Anyone who needs out-of-the-box performance can get it if
| they're willing to accept out-of-the-box security. Of
| course that doesn't make these side-channel attacks any
| less frustrating. For instance the original Meltdown and
| Spectre attacks were on my mind when I chose to "vote
| with my dollar" and buy an AMD CPU, only to end up with
| Zenbleed this year lol
| badrabbit wrote:
| They shouldn't have to accept OOB security flaw that was
| not disclosed intentionally at the time of purchase. If
| intel just made that information public when they found
| out, your argument would be valid. They could have also
| purchased different processors.
| qchris wrote:
| Isn't this sort of what the lawsuit is for, though? Even if
| it's cheaper to make the initial defective product and say
| you're sorry after, if the sorry is both guaranteed
| (prosecuting even the long tail) and large enough, then
| hopefully at some point it raises the overall cost to the
| point where it's now cheaper to build things correctly.
| hnfong wrote:
| Are we really going to essentially outlaw releasing buggy
| software now? And taking down software and services once
| a security issue has been found? Because I don't think
| any software I wrote was ever 100% bug-free.
|
| And all bugs are potentially a security issue.
| remram wrote:
| We're talking about _known security bugs_ , not just
| bugs. Stop with the strawman.
| pjmlp wrote:
| Just like everyone else is susceptible to lawsuits for
| bad services, faulty products, or ...
| pjmlp wrote:
| Hopefully, it is time that quality control in the industry
| reaches parity with other industries.
| mibsl wrote:
| The problem described in 2018 seems completely unrelated to
| downfall. It looks like a potential optimization to the original
| spectre, doesn't even mention AVX gather instructions.
|
| I don't see this going anywhere.
| yyyk wrote:
| * I can't think of any case where Downfall or the AVX
| vulnerabilities have been used in the wild. It seems too
| complicated/unnecessary to use in practice even against high-
| value targets. The lawsuit cannot demonstrate real damage or risk
| for the plaintiffs if the mitigation is just turned off. (It may
| be a real risk in other settings like Cloud hosting - but none of
| these companies filed or joined the lawsuit)
|
| * Even if we completely accepted the prosecution's dubious
| theory, the buyers had 5 years of decent use of the product.
| That's an acceptable period for warranties and a typical personal
| computer lifetime.
___________________________________________________________________
(page generated 2023-11-12 23:01 UTC)