Recommended reading

Researchers Disclose Meltdown-like Vulnerability for AMD Processors (Updated)

News
By published

Mitigations require software re-coding

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.

Original article:

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.

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.

See more CPUs News
TOPICS
10 Comments Comment from the forums
  • Papusan
    Yep, no HW is 100% secure. As a reminder...
    Reply
  • 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.
    Reply
  • InvalidError
    logainofhades said:
    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.
    Reply
  • 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.
    Reply
  • hotaru.hino
    waltc3 said:
    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.
    Reply
  • 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
    Reply
  • waltc3
    hotaru.hino said:
    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.
    Reply
  • hotaru.hino
    waltc3 said:
    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.
    Reply
  • cryoburner
    hotaru.hino said:
    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.
    Reply
  • InvalidError
    cryoburner said:
    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.
    Reply