News Researchers Disclose Meltdown-like Vulnerability for AMD Zen+ and Zen 2 Processors

[Admin]

The Meltdown-like "Transient Execution of Non-canonical Accesses" vulnerability impacts AMD's Zen+ and Zen 2 processors.

Researchers Disclose Meltdown-like Vulnerability for AMD Zen+ and Zen 2 Processors : Read more

 

[Papusan]

Yep, no HW is 100% secure. As a reminder...

 

[logainofhades]

Not surprising. Now that Ryzen is the most popular, people are looking for exploits on AMD, more so than in past years. There is always a back door into hardware/software, if you are talented enough, and lucky enough to find it.

 

[InvalidError]

There is always a back door into hardware/software

The term "backdoor" is usually reserved for things that were deliberately put in to circumvent security measures. Meltdown/Spectre type exploits mainly exist because engineers optimized things for performance and may not have foreseen the ways these optimizations could at least hypothetically be used to bypass normal security and require developers to take extra steps such as using load/store fences to guard absolutely critical secret bits better.

 

[waltc3]

Sigh, one day people will figure these things out properly without exaggerating them. I don't know when that will be...but anyway, the PSP bug is not a bug in the AMD security chip, or in the AMD CPU, as it has been erroneously described in various publications--it's a bug in the PSP driver that was fixed in the latest chipset drivers--which contained the updated PSP driver. That's why no firmware or OS microcode updates were required to fix it.

Additionally, this instance sounds like purely a software flaw in which AMD is instructing the software vendors who have employed the suspect instruction in their software to use another instruction instead, LFENCE, in the microscopic event that all of the conditions align perfectly in order for someone's mystery illicit code to function in that vendor's software. Similar to the RDRAND situation a couple of years ago--which is an Intel-specific bit of archaic code few use anymore that did not function optimally in the AMD architecture--AMD instructions then were similar--use another instruction on newer code. And that was that. I think in the Rdrand situation an AGESA update did fix it, but as I say it was not a concern except in outlier cases of older/poorly written Intel-optimized software, imo. It was actually a compatibility problem as opposed to a flaw.

People really have to stop panicking every time something like this comes up because the chance is 100,000-1 against, at least, that you will never be affected by it. People today panic at the drop of a hat it seems...everything is alarmist. I mean "Meltdown"...?.... Sorry, but no CPUs were ever melted.... Who thinks up this stupid stuff, I wonder? Last time I looked it was Google making up the silly names...

I guess people jump on imagined or real AMD CPU bugs because Ryzen has so few of them compared to currently shipping Intel CPUs. In this article, for instance, there is nothing here that concerns the Tom's readership, and nothing they (or I) can do except what they should be doing anyway--installing the latest driver updates for their systems, including AMD's chipset drivers. Always good, though, to be reminded that keeping your systems updated is simply a part of owning & maintaining a computer and so ought to be done on a regular basis.

 

[hotaru.hino]

I guess people jump on imagined or real AMD CPU bugs because Ryzen has so few of them compared to currently shipping Intel CPUs.

And it's precisely this reason why people are quick to jump on Zen any time an issue crops up. Zen is not only a relatively new microarchitecture, but it's one that's fast gaining ground across our infrastructure. That means we're putting something we don't really know about into potentially critical systems. From a security standpoint, that's kinda scary. The more we can know, identify, and characterize, the better we are for it.

Just because something has a lower count in the CVE list doesn't mean it's more secure. If we were to think that fewer CVE items = more secure, Linux should be immediately tossed out and we should be using Windows 98.

 

[Papusan]

If you have the gifts/talent you can find a ways to go into any systems. AMD or Intel doesn't matter. For normal people, just don't click on everything you find on internet/email. HW flaws will always be there regardless of brand. Same also for bugs in OS, drivers, software and firmware.
Always something new https://www.tomshardware.com/news/code-hides-in-gpu-memory

 

[waltc3]

And it's precisely this reason why people are quick to jump on Zen any time an issue crops up. Zen is not only a relatively new microarchitecture, but it's one that's fast gaining ground across our infrastructure. That means we're putting something we don't really know about into potentially critical systems. From a security standpoint, that's kinda scary. The more we can know, identify, and characterize, the better we are for it.

Just because something has a lower count in the CVE list doesn't mean it's more secure. If we were to think that fewer CVE items = more secure, Linux should be immediately tossed out and we should be using Windows 98.

And conversely, when a CPU has many more holes and vulnerabilities and firmware and OS microcode patches, I think it's safe to say it isn't more secure because of it... Also, EPYC is pounding Xeon, atm, in installations and demand--and I know of not a single soul using your inverse logic... Perhaps you should rethink.

Anyway, if Intel ships Alder Lake at some point, will you say that Intel's older, buggier CPUs are better? I mean, Intel will be burning the midnight oil making sure the AL vulnerabilities are as close to 0 as it can make them (of course).

Last, it's for certain that Intel has had dozens of people working hard--plus outside contractors it pays--to find holes and problems with Zen/Zen2/3. The results are fruitless as of this moment. Zen2/3 & EPYC are extremely well-thought-out and executed CPUs. Intel has its work cut out for it. Zen 4 is around the corner.

 

[hotaru.hino]

And conversely, when a CPU has many more holes and vulnerabilities and firmware and OS microcode patches, I think it's safe to say it isn't more secure because of it... Also, EPYC is pounding Xeon, atm, in installations and demand--and I know of not a single soul using your inverse logic... Perhaps you should rethink.

Anyway, if Intel ships Alder Lake at some point, will you say that Intel's older, buggier CPUs are better? I mean, Intel will be burning the midnight oil making sure the AL vulnerabilities are as close to 0 as it can make them (of course).

Last, it's for certain that Intel has had dozens of people working hard--plus outside contractors it pays--to find holes and problems with Zen/Zen2/3. The results are fruitless as of this moment. Zen2/3 & EPYC are extremely well-thought-out and executed CPUs. Intel has its work cut out for it. Zen 4 is around the corner.

The thing with security is that knowing that you have flaws is better than not knowing you have flaws. Knowing you have flaws means you have the information to best address them for your use case. Plus by the time something was made public on the CVE list, either it's been fixed already or there are known mitigations in place to make the problem less effective. The CVE list exists to make issues known so that A. you're aware and B. you can formulate a plan if you need to use something with the flaw.

To put this in a more real-world case:

• Scenario 1: I know anyone can bust into my home by throwing a brick at the windows. Do I go out and buy some sort of protection on my windows to prevent this? No, because I'm not in a high threat environment where doing that would make a difference. I'm aware I have a security flaw, but I don't really care about addressing it because it's not a problem.
• Scenario 2: Let's say that I'm in an high threat environment and I reinforce my windows. But maybe I don't pay attention to my doors, I don't know my doors are a weak point so I don't bother with them. Now I'm in a more precarious situation if someone kicks down my door because I don't have a plan to deal with it
• Scenario 3: Same as Scenario 2, but I'm aware of my doors being a problem, but I can only afford to either reinforce the doors or the windows. I opt to do the windows and leave the doors alone. But I'm aware the doors are a problem so I can formulate a plan around someone kicking down the door, like say leaving worthless jewelry in a bowl close by so a thief takes those and runs.

Another point is security is it's about risk management. You can't have a 100% secure system and it's not always feasible to get as close to it as possible. So you take a look at what's available to you, figure out what issues there are with it, assess the risks, and make a plan/decision from there.

 

[cryoburner]

The thing with security is that knowing that you have flaws is better than not knowing you have flaws. Knowing you have flaws means you have the information to best address them for your use case.

Except knowing that hardware has certain flaws doesn't actually provide you with any assurance that there are not additional flaws that are not yet publicly known. I would hardly say that having more known flaws can be considered a good thing when you have no way of knowing how many unknown flaws still exist.

 

[InvalidError]

Except knowing that hardware has certain flaws doesn't actually provide you with any assurance that there are not additional flaws that are not yet publicly known. I would hardly say that having more known flaws can be considered a good thing when you have no way of knowing how many unknown flaws still exist.

Practically everything has flaws, you just don't know about them. And a lot of these side-channel type exploits are applicable to many modern CPUs spanning multiple ISAs in slightly different forms since they are artefacts of contemporary high-performance CPU design techniques.