News AMD's Zen 3 CPUs Are Susceptible To Spectre-Like Vulnerability

[Admin]

AMD publishes whitepaper on a potential Spectre-like vulnerability that affects the company's Zen 3 processors.

AMD's Zen 3 CPUs Are Susceptible To Spectre-Like Vulnerability : Read more

 

[Kamen Rider Blade]

Good on AMD for disclosing the security vulnerability instead of relying on outside 3rd parties to do it.

I'm sure their security team is hard at work figuring out a micro-code solution to solve it.

 

[Deleted member 2871437]

So you're probably safe to leave Predictive Store Forwarding on, but if you're worried turn it off and maybe loose some performance.

 

[thGe17]

Good on AMD for disclosing the security vulnerability instead of relying on outside 3rd parties to do it.

I'm sure their security team is hard at work figuring out a micro-code solution to solve it.

Why should this be "good"? Whoever comes first ... if AMD found it (or stumbled upon it first), they must disclose it, otherwise it would be a very questionable practice.

And again, there's currently no "real/final solution" or "fix" for this Spectre-v4-like problems. They all use a combination of some HW-assisted optimizations and OS/VMM adjustments and pointing to coding standards to build some kind of mitigation.
This has been already shown in a Zen2 release-sheet and for Zen3 AMD avoided to publish such a sheet again, because nothing has changed. And now, they've additionally implemented a new way of Spectre-v4-like attacks with this new feature.
Nowadays, CPUs are so complex that security is really difficult to achieve and additionally, these are sometimes conflictive goals: you wanna implement a more powerful, faster architecture (to be more competitive) and you wanna keep or even increase security ...

 

[InvalidError]

Nowadays, CPUs are so complex that security is really difficult to achieve and additionally, these are sometimes conflictive goals: you wanna implement a more powerful, faster architecture (to be more competitive) and you wanna keep or even increase security ...

Every speculative feature opens the door to hypothetical side-channel leaks (no practical exploit actually exists) from detecting speculation changes. If your code requires the highest level of security, don't run it on a shared machine where unknown processes may be eavesdropping. Maybe even go a step further and seclude the absolutely critical parts like root keys and certificates on FPGAs that will handle all manipulations involving them.

 

[macgeek]

I noticed that there's one tidbit missing from both the article and AMD's whitepaper: Whether this bug be exploited remotely or if physical access would be required.

 

[Deleted member 2871437]

I noticed that there's one tidbit missing from both the article and AMD's whitepaper: Whether this bug be exploited remotely or if physical access would be required.

I don't see anything in the article suggesting physical access is required for this exploit so the safer assumption if you're worried is that (hypothetical) remotely executed code might exploit the vulnerability. All pretty speculative at the moment.

 

[Gomez Addams]

Why should this be "good"? Whoever comes first ... if AMD found it (or stumbled upon it first), they must disclose it, otherwise it would be a very questionable practice.

And again, there's currently no "real/final solution" or "fix" for this Spectre-v4-like problems. They all use a combination of some HW-assisted optimizations and OS/VMM adjustments and pointing to coding standards to build some kind of mitigation.
This has been already shown in a Zen2 release-sheet and for Zen3 AMD avoided to publish such a sheet again, because nothing has changed. And now, they've additionally implemented a new way of Spectre-v4-like attacks with this new feature.
Nowadays, CPUs are so complex that security is really difficult to achieve and additionally, these are sometimes conflictive goals: you wanna implement a more powerful, faster architecture (to be more competitive) and you wanna keep or even increase security ...

Yes, there is. The fact is you can eliminate all possibility of any of these attacks occurring by NOT allowing malicious software on your machine in the first place. Problem solved!

 

[GenericUser]

Why should this be "good"? Whoever comes first ... if AMD found it (or stumbled upon it first), they must disclose it, otherwise it would be a very questionable practice.

It's "good" in the sense that they are being upfront and working towards a solution, as opposed to what some other companies will do, which is sit on internally discovered vulnerabilities and decide they just aren't going to fix them, or get notified by a third party of a discovered vulnerability, then that third party has to disclose the vulnerability publicly to force the company's hand because they also decided in that case they weren't going to fix it. Sure it's a questionable practice like you say, yet several companies decided to do exactly that: nothing.

 

[macgeek]

I don't see anything in the article suggesting physical access is required for this exploit so the safer assumption if you're worried is that (hypothetical) remotely executed code might exploit the vulnerability. All pretty speculative at the moment.

The reason I mention it is because they've had vulnerabilities like this in the last few years, but most of them could only be exploited locally.

 

[Kamen Rider Blade]

Why should this be "good"? Whoever comes first ... if AMD found it (or stumbled upon it first), they must disclose it, otherwise it would be a very questionable practice.

And again, there's currently no "real/final solution" or "fix" for this Spectre-v4-like problems. They all use a combination of some HW-assisted optimizations and OS/VMM adjustments and pointing to coding standards to build some kind of mitigation.
This has been already shown in a Zen2 release-sheet and for Zen3 AMD avoided to publish such a sheet again, because nothing has changed. And now, they've additionally implemented a new way of Spectre-v4-like attacks with this new feature.
Nowadays, CPUs are so complex that security is really difficult to achieve and additionally, these are sometimes conflictive goals: you wanna implement a more powerful, faster architecture (to be more competitive) and you wanna keep or even increase security ...

You should've seen how Intel dragged their feet and initially denied the exist of Spectre/MeltDown until it became too obvious that they had to admit to it.

 

[hotaru.hino]

You should've seen how Intel dragged their feet and initially denied the exist of Spectre/MeltDown until it became too obvious that they had to admit to it.

While yes, the original team, Google's Project Zero, the discovered the flaw in mid 2017 and Intel formally reported in Jan 2018, that doesn't mean Intel was denying it. The Project Zero team wanted to publicly disclose the vulnerability in Jan 2018 anyway.

If anything I'd imagine Intel downplaying it. After all, there are papers out there written about ways to exploit implementations of x86 processors dating back since the 90s. But the thing is, security is all about risk management. If the risk of the thing actually happening is small enough and the resources to put up a mitigation against it are too costly, then it's not going to be addressed.

Or as I like to put it, you could build your home like Fort Knox, but if there's zero risk of someone breaking in and stealing your valuables, why bother?

Good on AMD for disclosing the security vulnerability instead of relying on outside 3rd parties to do it.

I'm sure their security team is hard at work figuring out a micro-code solution to solve it.

You kind of want third parties to poke and prod at your stuff and report it. It helps keep whom they poke and prod at accountable. What if AMD knew this was a thing for years but decided now that they should report it?

 

[Kamen Rider Blade]

You kind of want third parties to poke and prod at your stuff and report it. It helps keep whom they poke and prod at accountable. What if AMD knew this was a thing for years but decided now that they should report it?

I'm all for 3rd party poking & prodding. But AMD got to this security vulnerability first, and reported it without dilly dallying or waiting on 3rd party to force their hand.

That should be commended.

 

[hotaru.hino]

I'm all for 3rd party poking & prodding. But AMD got to this security vulnerability first, and reported it without dilly dallying or waiting on 3rd party to force their hand.

That should be commended.

We don't know that they reported it immediately or took their time with it. Maybe they've only reported it after someone actually figured out a practical way to exploit the vulnerability.

I just don't see how it's big news that AMD themselves reported it.

EDIT: I mean, was there any big news that Intel independently discovered and fixed the Memory Sinkhole problem? I certainly don't recall. It only got news when someone else discovered and presented it two years later.

 

[Gillerer]

Or AMD discovered the vulnerability and then took some time to analyze it to see how hard it would be to fix or mitigate. Reporting it immediately without knowing much about it would be irresponsible.

If there is an easy (an inexpensive in terms of performance and functionality) fix that's ready to roll there is really no reason to delay informing the public. Quite the opposite: You could see such a move as a campaign move to get OS vendors to adopt their proposed changes.

If on the other hand developing an effective fix would take a few more months it would be important to keep things out of the public eye as long as possible, so there is less chance of someone having time to develop an exploit.

 

[hotaru.hino]

On an aside, I looked back into Memory Sinkhole's history. While Intel did fix it from Sandy Bridge and on, they didn't officially acknowledge it until 2015 when the researcher (Chris Domas) publicized it. So on one hand, I can see AMD being better at actually being forthcoming with a problem.

However I still don't see it being a big deal. First party security reports should always be taken with a grain of salt until verified by a third party.