Update, 8/31/2021 7:30am PT: Updated article and title to clarify that the vulnerability applies to all AMD processors, not just the Zen 2 and Zen+ models listed in the research paper.
According to security researchers and AMD, the company's Zen 2 and Zen+ processors suffer from a new Meltdown-like vulnerability, but the problem appears to be far more wide-ranging. AMD has prepared a guide on mitigating the vulnerability and published details about how the vulnerability works, but the company's security bulletin also notes that all AMD CPUs are vulnerable. Called "Transient Execution of Non-canonical Accesses," this vulnerability acts very similarly to the already-disclosed Meltdown vulnerability that only impacts Intel CPUs.
Saidgani Musaev and Christof Fetzer, researchers from Dresden Technology University, discovered the vulnerabilities in AMD Zen+ and Zen 2 processors. The researchers disclosed the CVE-2020-12965 vulnerability to AMD in October 2020, giving the company enough time to develop a mitigation technique that AMD has addressed in the official paper on Arxiv (PDF) and AMD's security website.
The Transient Execution of Non-canonical Accesses vulnerability works by simply combining specific software sequences, where AMD CPUs "may transiently execute non-canonical loads and store using only the lower 48 address bits potentially resulting in data leakage." This data leakage is later exploited to access possible secrets stored in the computer, leading to a security problem.
AMD recommends that all software vendors that ship code for its platforms revisit their programs and add mitigations. For example, the company recommends using LFENCE (Load Fence) instructions in the software or any of the existing speculative execution mitigations disclosed in the software manuals here (opens in new tab).
Last week, AMD issued driver patches for Ryzen chipsets that support the Zen+ and Zen 2 architecture without explicitly stating what was fixed. However, the company did note that the patches address an issue in the Platform Security Processor. AMD tells us that those patches aren't related to the Transient Execution bug.
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.
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.
Always something new https://www.tomshardware.com/news/code-hides-in-gpu-memory
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.
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.