Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone with no article paywalls. Just good, fresh content! Alternatively, you can donate through PayPal, Liberapay or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.

Thought Intel was the only one? Well you would be living under a rock with all the past issues but Intel seemed to be constantly hit harder, and they had another recently. This time, it's AMD's turn in the security spotlight.

Researchers from 'Graz University of Technology', 'Univ Rennes, CNRS, IRISA' and another unaffiliated with either have released a paper with a security issue named 'Take A Way' which affects AMD CPUs going back to 2011 affecting a huge amount of them.

We reverse-engineered AMD’s L1D cache way predictor in microarchitectures from 2011 to 2019, resulting in two new attack techniques. With Collide+Probe, an attacker can monitor a victim’s memory accesses without knowledge of physical addresses or shared memory when time-sharing a logical core. With Load+Reload, we exploit the way predictor to obtain highly-accurate memory-access traces of victims on the same physical core. While Load+Reload relies on shared memory, it does not invalidate the cache line, allowing stealthier attacks that do not induce any last-level-cache evictions.

They did the responsible thing with it, and notified AMD on this particular issue on August 23rd, 2019 so AMD has had plenty of time to come up with possible fixes for it.

Interestingly, when you look over who funded this research it's had multiple backers—including "generous gifts from Intel". This isn't exactly unusual though, Intel funds a lot of things around security and it doesn't appear to be some kind of directed attack on AMD. One of the people named on the paper, Daniel Gruss, has been clearing it up on Twitter (#1, #2).

AMD themselves released a statement yesterday, which reads:

We are aware of a new white paper that claims potential security exploits in AMD CPUs, whereby a malicious actor could manipulate a cache-related feature to potentially transmit user data in an unintended way. The researchers then pair this data path with known and mitigated software or speculative execution side channel vulnerabilities. AMD believes these are not new speculation-based attacks.

Obviously, AMD recommend keeping your PC software and firmware up to date.

It's been a tough few years for both Intel and AMD, and likely will continue to be so as more research is done to find more holes. While it's somewhat frightening there's been so many, it's great that they are found so they can be fixed through updates or new silicon rather than going unnoticed and potentially abused.

Article taken from GamingOnLinux.com.
13 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
20 comments
Page: 1/2»
  Go to:

ljrk 8 Mar, 2020
And the tinfoil is already heavily heating up over at r/AMD, people found out that two of the PhD students there have been funded by Intel. They totally miss though, that these researchers have already found some Intel vulns like Meltdown etc., also being funded by Intel.

It's getting worse because this vulnerability is only presenting a new attack vector on one component but not a complete exploit for patched hardware. Again, people ignore how research works: You focus on *one* critical component, because doing otherwise would mean never being actually done. Although this vulnerability is not exploitable, it adds a puzzle piece to the toolbox that might prove useful if the current Speculation-attack countermeasures fail or someone finds a completely different way to use this vector. Or someone might be inspired by this *completely new approach* to find an exploit that works without disabling aforementioned countermeasures. This is research, not a security review (and, well, being someone who does security reviews, we do also mention unexploitable vulnerabilities because you never know...).


Last edited by ljrk on 8 March 2020 at 11:20 am UTC
SirLootALot 8 Mar, 2020
So if it is just a new way to exploit previously known speculative execution vulnerabilitys, is it really a new attack?
soulsource 8 Mar, 2020
Exactly. Three of the authors of the new paper were also directly involved in developing the KAISER mitigation for Meltdown (which has been meanwhile renamed to KPTI):
Moritz Lipp (first author, meaning he probably wrote most of the paper), Michael Schwarz and Daniel Gruss (last author, meaning he probably takes responsibility for the paper's content)

https://lwn.net/Articles/738997/
Liam Dawe 8 Mar, 2020
Quoting: SirLootALotSo if it is just a new way to exploit previously known speculative execution vulnerabilitys, is it really a new attack?
A new way to use something existing, is still new, especially when it has only just now been publicly announced. So yes, it's new.
SirLootALot 8 Mar, 2020
Quoting: Liam Dawe
Quoting: SirLootALotSo if it is just a new way to exploit previously known speculative execution vulnerabilitys, is it really a new attack?
A new way to use something existing, is still new, especially when it has only just now been publicly announced. So yes, it's new.
Should have worded that differently. You are right it is obviously a new attack but the vulnerability stays the same afaik. If I disable speculative execution or were to somehow magically fix all the spectre attack-vectors this would not be an issue. This is just how to utilize the vulnerabilitys if I understand correctly. That's what i wanted to say.
Nanobang 8 Mar, 2020
Ok, there's a security issue, but what is the security issue exactly, please? I see they both involve "shared memory," but that's about all I can really understand from the paragraph, and since I don't know what that is, I don't really understand anything.

Is this something I need to be concerned about, really? Or is this one of those security exploits requiring, like, someone has physical access to the computer, is logged in as root, and has a valid driver's license in 3 countries or some such?
PublicNuisance 8 Mar, 2020
Can't wait for open source CPUs to become more popular and powerful.
ajgp 8 Mar, 2020
Quoting: PublicNuisanceCan't wait for open source CPUs to become more popular and powerful.

Only problem with that is any Open Source CPU would have to be of an architecture other than x86 / X86_64 as these are locked by Intel & AMD respectively and Intel is fairly adamant on no-one else ever getting an X86 license (the only other would be VIA).

So any open source CPU would most likely be ARM based, that leaves you in the whole what will be compiled to run on it scenario. A powerful CPU that wont run applications that people use daily will never gain traction.
grigi 8 Mar, 2020
ARM restricts their property too, so can't be totally open source.
Let's face it, OSS's strong point is allowing itself to break ABI.

These vulnerabilities are not directly exploitable, but they can be used to build a model of behviour, and that can be used to spy on people. So it should be adressed.
I wouldn't be surprised that a similar exploit could work on all cpu's with prefetchers. (a larger set than those with speculative execution).
sub 8 Mar, 2020
Quoting: ajgp
Quoting: PublicNuisanceCan't wait for open source CPUs to become more popular and powerful.

So any open source CPU would most likely be ARM based (...)

Most likely RISC-V
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.