• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.
  • The forums have been upgraded with support for dark mode. By default it will follow the setting on your system/browser. You may override it by scrolling to the end of the page and clicking the gears icon.

AMD Is Served: Class Action Lawsuit Launched Over Spectre Vulnerabilities

Well Since AMD knew of the flaw before they put their Ryzen cpu's on sale they are in same boat as they can claim against intel. If people claim intel should halted release of their cpu so should have AMD when hearing of said problem as they cpu's yes were launched but it was paper launch and not launched as on sale that you could get it.

This only effects cpu's that they KNEW of the flaw in so intel they can only go after for cpu's that were launched after.

You can not prove that AMD knew this.
 
Why? The bug is patchable and replacing every CPU impacted by this would take more than a couple years and an enormous amount of money on Intel's part (if you consider that this would mean practically every single CPU in Google and Amazon's data centers,) I would expect them to fight tool and nail, even in collaboration with AMD, to prevent that from happening. Rightfully so though. When a car has a recall, they fix the problem, they don't typically replace the car and patching this fixes the problem.
Only Intel processors that would qualify are E3-1285 v6, most of the C3### series, several Skylake-E processors, and some Xeon W-21## series. These are processors intended to run VMs that were released, without notifying the customers, after Intel was notified of the branch target injection vulnerability. Customers were mislead.

The "fix" creates a performance problem which can't be fixed. It's akin to buying a car that bursts into flames and they "fixed" that problem via an ECU patch that reduces the rated horsepower by 30%; the people that bought the car will probably want a refund or a second recall that fixes the original problem permanently.

You can not prove that AMD knew this.
Everyone got notified six months before the public was notified. It's typically how zero-day exploits are rolled out.
 
Everyone got notified six months before the public was notified. It's typically how zero-day exploits are rolled out.

Yes, but which SKUs has AMD launched since then? Plus, until a few weeks ago they seemed to be convinced their CPUs are not vulnerable, so if this goes to court, it's going to be hard to prove they launched anything knowing it was affected by a vulnerability.
Anyway, let's not try AMD here. Leave that to the courts and then we can discuss.
 
The "fix" creates a performance problem which can't be fixed. It's akin to buying a car that bursts into flames and they "fixed" that problem via an ECU patch that reduces the rated horsepower by 30%; the people that bought the car will probably want a refund or a second recall that fixes the original problem permanently.
Except performance loss isn't 30% on average so, exaggeration notwithstanding, it would be more akin to a 5% power loss. This is more like saying, "Yeah, we put an over-sized pulley on the AC and alternator so, output was too low. So we switched out the larger pulleys with smaller ones and everything is good except for the accessories sap a little more power from the engine than it did before to maintain proper output." That's also not misleading because the engine still produces that much power when dyno'ed at the crank because most power numbers are at the wheels after all of the drivetrain losses. In fact, most engines dyno'ed at the crank don't even have accessories setup. CPUs are similar in the sense that it doesn't impact flaw FLOPS or MIPS or whatever raw measure you use but, otherwise impacts performance due to the software. Spectre doesn't make the CPU burst into flames, it just doesn't always behave as expected and hardware erratas crop up all the time.
 
Why? The bug is patchable and replacing every CPU impacted by this would take more than a couple years and an enormous amount of money on Intel's part (if you consider that this would mean practically every single CPU in Google and Amazon's data centers,) I would expect them to fight tool and nail, even in collaboration with AMD, to prevent that from happening. Rightfully so though. When a car has a recall, they fix the problem, they don't typically replace the car and patching this fixes the problem.

Doesn't mean it can't and won't happen, look no further than Volkswagen they're still in the process of scrapping/exporting all the vehicles they had to buyback because they couldn't be fixed.
 
Yes, but which SKUs has AMD launched since then?
EPYC, Ryzen PRO, APUs, Ryzen 3 and 5.
edit: I forgot about Threadripper. But it seems everyone has forgotten anyway. :-P
Plus, until a few weeks ago they seemed to be convinced their CPUs are not vulnerable, so if this goes to court, it's going to be hard to prove they launched anything knowing it was affected by a vulnerability.
You're suggesting they didn't understand the report from Project Zero? Or maybe that they don't know how their CPUs work?
Anyway, let's not try AMD here. Leave that to the courts and then we can discuss.
Does this apply to Intel as well? :p
 
Last edited:
Except performance loss isn't 30% on average so, exaggeration notwithstanding, it would be more akin to a 5% power loss. This is more like saying, "Yeah, we put an over-sized pulley on the AC and alternator so, output was too low. So we switched out the larger pulleys with smaller ones and everything is good except for the accessories sap a little more power from the engine than it did before to maintain proper output." That's also not misleading because the engine still produces that much power when dyno'ed at the crank because most power numbers are at the wheels after all of the drivetrain losses. In fact, most engines dyno'ed at the crank don't even have accessories setup. CPUs are similar in the sense that it doesn't impact flaw FLOPS or MIPS or whatever raw measure you use but, otherwise impacts performance due to the software. Spectre doesn't make the CPU burst into flames, it just doesn't always behave as expected and hardware erratas crop up all the time.
Even at 5%, that's basically like losing a core on a 16-core processor. That's significant, especially for cloud computing.

Yes, but which SKUs has AMD launched since then?
Several Ryzen Threadrippers and the Ryzen APUs. Threadripper has a stronger argument in court.
 
What did i say in the intel version of this thread.....premature lawsuit is premature...
 
EPYC, Ryzen PRO, APUs, Ryzen 3 and 5.

The vulnerabilities were reported on June 1, 2017, so I'm not sure Ryzen 3 and 5 belong there. But whatever.

You're suggesting they didn't understand the report from Project Zero? Or maybe that they don't know how their CPUs work?

I'm suggesting they didn't have conclusive proof their CPUs were affected. Their public statements seems to indicate they were convinced they were safe because their implementation is different from Intel's. To be taken with a grain of salt, but atm there's no proof they were lying or anything.

Does this apply to Intel as well? :p

Absolutely. The only difference is apparently the vulnerability was actually demonstrated at the time on at least some Intel CPUs. Otherwise, they both get the benefit of the doubt from me.
 
Totally correct. Everyone who manufactures CPU's was notified using known good practices. Everyone got the same heads-up and everyone got the same amount of time to work the problem. This case, if it actually sees time in court, will fall to dust as it is, as AMD rightly said, without merit. To that I will add, laughable.

I think people that are saying this are missing the point of these lawsuits. They aren't suing because AMD processors have the vulnerability, they are suing because when AMD went public about the vulnerability they said their processors were not vulnerable when it turned out they were. They said they weren't vulnerable to Spectre 2, then they changed that to "near zero" possibility of exploiting Spectre 2 on their processors. Well, near zero is not zero, and any possibility of exploitation needs to be addressed and they failed to do that.

That said, I don't think these lawsuits are warranted personally, but I can see where people might think otherwise and blame AMD for releasing mis-information about security issues with their products.

Yes, but which SKUs has AMD launched since then?

They launched the Ryzen 3 processors, as well as ThreadRipper, Epyc , and the mobile lineup of Ryzen. But this doesn't really have anything to do with the lawsuits. These lawsuits aren't about launching products with known vulnerabilities. It is about AMD falsely claiming they were not affected by Spectre 2, then changing their mind and saying their actually are affected by Spectre 2. That is the issue the lawsuits are based on.

Plus, until a few weeks ago they seemed to be convinced their CPUs are not vulnerable, so if this goes to court, it's going to be hard to prove they launched anything knowing it was affected by a vulnerability.

And that is going to be the argument the court has to decide on. Since they were definitely alerted that the vulnerability existed. They had a significant amount of time to determine if their processors were affected or not. And once the vulnerability hit the news, they changed their story a few times about if their processors were affected or not.

So either they were either negligent in not even bothering to test their products to determine if they were affected when they were informed of the vulnerabilities and before making a statement to their customers, or they knew about the vulnerabilities but lied when they originally made their statements about how their products were affected by the vulnerabilities. Either way, both scenarios are reason for a court to at least hear the lawsuit and make a decision.
 
Last edited:
Again, it would be great if people knew what they were talking about before posting. Intel uses a branch target buffer to store branch memory locations.
THIS is the PRIMARY vulnerability that Spectre 2 uses. AMD does NOT use a BTB. Just like AMD doesn't execute commands on page fault memory
for Meltdown. This makes it extremely difficult to exploit Spectre 2 and impossible for Meltdown. How extremely difficult? I've read that internal hardware
access is needed on an AMD pc (i.e. access to pins on board). Ryzen cpus have DIFFERENT hardware operations, and are NOT the same as Intel.

They are adding an indirect branch prediction barrier and single thread branch prediction barrier firmware just in case. Since Spectre 2 uses the BTB similar
to the page faults in meltdown, and AMD uses fixed memory addresses, Specter cannot change memory locations to store data.
The two items they are adding to the AGESA just make sure the branches stay in their own lanes, so to speak. Just insurance, that's all.

To fix Intel, indirect branch restricted speculation must be added to the firmware. This prevents BTB exploits, but might have a performance hit for some
workloads again, similar to Meltdown
 
I'm suggesting they didn't have conclusive proof their CPUs were affected. Their public statements seems to indicate they were convinced they were safe because their implementation is different from Intel's. To be taken with a grain of salt, but atm there's no proof they were lying or anything.

.

well , There is at least according to notb !
 
The vulnerabilities were reported on June 1, 2017, so I'm not sure Ryzen 3 and 5 belong there. But whatever.
You're right. Not true for Ryzen 5. Still true for 3 and PRO.
I'm suggesting they didn't have conclusive proof their CPUs were affected. Their public statements seems to indicate they were convinced they were safe because their implementation is different from Intel's. To be taken with a grain of salt, but atm there's no proof they were lying or anything.
But they got PoCs from Project Zero - even for Meltdown. Code and stuff...
Are you telling me they weren't able to reproduce the results? Now you're suggesting they have very poor programmers on board. Maybe they should hire someone else? I've heard there are some talented guys in Graz. :-P

AMD is either lying or showing serious incompetence. Which is worse?

Lets put giant Intel aside.
Arm, having exactly the same material from Project Zero, 25% of AMD's revenue and 30% of staff, managed to reproduce the issues, check all their architectures and even show that they're vulnerable to Meltdown (something Project Zero couln't achieve).
 
Imagine if Microsoft were held liable for every serious bug over the years… They would have been bankrupt a long time ago.

Did AMD mislead the public about these bugs? Sure, but how many customers were fooled during those few days?

They can make a case for Threadripper and Raven Ridge. In the case of Raven Ridge, the damages are minimal because there's not much exposure to VMs. Any claims against that will likely be thrown out. Threadripper though, AMD could be in as much trouble as Intel. They knew about the problem but said absolutely nothing about it and launched the product anyway. They are processors aimed at running VMs.
Virtual machines have nothing to do with these defects, VMs are just one of the ways it can be exploited. Any piece of code which can precisely time the execution of certain system calls and other operations can do this, including but not limited to Java applets, Android apps, various scripts and any compiled binary. If I can somehow run a piece of code on a physical machine containing your data, I can in theory reach it. Even Mozilla has tweaked their JavaScript implementation to mitigate the problems. This is not a problem limited to virtual machines in the cloud.
 
But they got PoCs from Project Zero - even for Meltdown. Code and stuff...
Are you telling me they weren't able to reproduce the results? Now you're suggesting they have very poor programmers on board. Maybe they should hire someone else? I've heard there are some talented guys in Graz. :p

AMD is either lying or showing serious incompetence. Which is worse?

Lets put giant Intel aside.
Arm, having exactly the same material from Project Zero, 25% of AMD's revenue and 30% of staff, managed to reproduce the issues, check all their architectures and even show that they're vulnerable to Meltdown (something Project Zero couln't achieve).
Afaik, Project Zero only prove the exploit on Intel. AMD was warned, but they didn't seem to be able to actually check the exploit can work on AMD hardware until very recently. The setup for exploiting these vulnerabilities is very complex, so I'm not surprised this wasn't reproduced quicker.
The report only said A8-9600 was vulnerable, but that's not Zen...

Either way, this is fixable, so it's all storm in a cup of water in the end.
 
Afaik, Project Zero only prove the exploit on Intel. AMD was warned, but they didn't seem to be able to actually check the exploit can work on AMD hardware until very recently.
Incorrect. They shown the exploit working on AMD A8 PRO. They even sent the code.
These materials are public. I've posted the link in reply to behrouz.
The setup for exploiting these vulnerabilities is very complex, so I'm not surprised this wasn't reproduced quicker.
All other companies succeeded.
As I said: Arm even managed to prove Meltdown vulnerability (PZ couldn't).

I expect more from a second largest CPU manufacturer. A lot more.
The report only said A8-9600 was vulnerable, but that's not Zen...
The role of security researchers like PZ is to find a vulnerability. It's manufacturers' role to further test them and check all CPU models they can find in storage.

In fact PZ worked with a fairly recent A8-9600 (it's already AM4). On the Intel side, it was a much older E5-1650 v3 from 2014 - possibly a hint on when they started working on this issue.
Either way, this is fixable, so it's all storm in a cup of water in the end.
No, it's not. The vulnerabilities will be patched (at least when we finally get patches that don't BSOD/brick computers), but we'll also learn a bit about the manufacturers.
Arm's reaction was perfect.
Intel's first reaction was... well... very typical for Intel. But they improved afterwards - also typical for them.
AMD's actions are not what we should expect. And AFAIK enterprise clients are far from amazed...

Once again: think about Meltdown.
The situation is as follows: researchers have suggested that the fundaments for a Variant 3 attack are also true for AMD CPUs. They didn't manage to make a successful attack, but they call it possible. The important part: they said exactly the same about ARM.

Arm admitted that their CPUs are vulnerable to all variants.
AMD said they are not vulnerable to either Variant 2 and 3. Experts around the world reacted with "hey guys, but we've seen Variant 2 working!".
So a week later AMD said that "OK, you're right. Variant 2 is also an issue" and added "but we still believe Variant 3 is not".

In the end a Variant 3 patch will also be applied to AMD systems anyway, so I don't know why they're fighting so much. It's like they didn't care about EPYC sales at all (in fact something I believe to be true :)).
 
Once again: think about Meltdown.
The situation is as follows: researchers have suggested that the fundaments for a Variant 3 attack are also true for AMD CPUs. They didn't manage to make a successful attack, but they call it possible. The important part: they said exactly the same about ARM.

They couldn't manage it doesn't mean "oh yes we can expect another Meltdown on AMD CPU"! lol
 
Virtual machines have nothing to do with these defects, VMs are just one of the ways it can be exploited. Any piece of code which can precisely time the execution of certain system calls and other operations can do this, including but not limited to Java applets, Android apps, various scripts and any compiled binary. If I can somehow run a piece of code on a physical machine containing your data, I can in theory reach it. Even Mozilla has tweaked their JavaScript implementation to mitigate the problems. This is not a problem limited to virtual machines in the cloud.
Except that's like any virus ever. What's unique about Spectre is that it can reach across VMs. If just one node is compromised, data from all of the nodes can be exposed. That goes beyond the scope of a typical virus. Spectre defeats the purpose of running in a VM in the first place.
 
Except that's like any virus ever. What's unique about Spectre is that it can reach across VMs. If just one node is compromised, data from all of the nodes can be exposed. That goes beyond the scope of a typical virus. Spectre defeats the purpose of running in a VM in the first place.
Running in a VM is not only about isolation, but you're right.
 
I don't get the timelines being posted. Tape out is pretty much the last changes to cpu designs, and this is usually over a year from release. Think test
wafers, engineering samples, respin if a mistake is found. Ramp up of wafer production. Wafers sent to be packaged (turned in to cpu's , not boxed).
and then build up enough inventory for release. Anything after ramp up pretty much means it's way too late to fix anything, even if you really wanted to.

AMD was probably well into threadripper by then, but, if you stop and think about it, ALL ryzen, TR, and epyc cpu's use the same cores, just different combinations
with parts fused off and adjusting for yields.

You MIGHT have a point with coffee lake, considering the lack of changes to the cores, but I doubt it. They probably had this taped out a while ago, which is how
they got it to market so quickly. It launched with no ramp up or inventory though, which is going on now. Still probably set before this happened.
 
Except that's like any virus ever. What's unique about Spectre is that it can reach across VMs. If just one node is compromised, data from all of the nodes can be exposed. That goes beyond the scope of a typical virus. Spectre defeats the purpose of running in a VM in the first place.
Sure, it's unusual that vulnerabilities let you reach across VMs, but the vulnerabilities themselves have nothing to do with VMs. That is a very important distinction.
Any code running on a machine can in theory exploit this. Including the 100 apps on your phone, Java applets and in theory JavaScript in your web browser.
 
I just found this article that explains which law firms are suing Intel and which are suing AMD.
http://www.game-debate.com/news/243...tdown-and-spectre-further-2-filed-against-amd
As an AMD cpu user I dont feel like I have been mislead when choosing this CPU since I didn't know about these exploits and this was the cpu I could afford. I dont understand why are the AMD shareholders being mad when AMD's shares went up when the story broke or the NDA was lifted. I guess they can be mad about the statement AMD made that there is a near zero chance spectre could infect the AMD architecture but still AMD made those test's known to the public and proved them self's wrong but still being mad about the near zero announcement is stupid in my opinion, but that is my opinion.
 
Java applets
I would expect that to be far less likely because memory in Java is isolated to the JVM and you can't do the required operations to get Specrte to occur in Java or any language that runs on the JVM without altering and recompiling the JVM itself. You kind of need a language that gives you access to C-level binding in order to do this in a higher level language. JavaScript on the other hand (in particular Node,) is a lot closer to hardware than one might think and that any number of extensions written in C for it could be used to do this.
 
Back
Top