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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: NanobangOk, 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?
I've not read the paper, but the vulnerability is in the predictor of the L1d cache
I don't know how much about caches you know, but basically it's that a subset of the data in the memory is loaded into a super-fast memory on the CPU. The L1d is the first-level (smallest, fastest) data-cache. I suppose the vulnerability aims to make applications leak data to another application via the cache, ie. read another applications data not from memory (which the kernel prevents) but somehow from the cache via speculative loads.
It is a new vulnerability insofar, as this has not been done or researched before. However for this to be exploitable, speculative execution needs to be exploitable, which isn't if the system is fixed -- at least, that's the current state of the art. And that's the important takeaway: Although exploiting might currently need disabling fixes first, maybe someone else will find a way to use this vulnerability w/o disabling the fixes.
1 Likes, Who?
PublicNuisance Mar 8, 2020
Quoting: ajgpQuoting: 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.
We're all here using an OS for gaming that has a market share of less than 1% and has taken years and years to get the little traction in gaming that it has yet here we are plowing forward. There's tons of programs that don't work on Linux out of the box but we adapt and overcome, same can be done on another architecture. The advancement of ARM based Linux phones may be a big deal in the next few years if ARM based open source CPUs do end up being an option. Nothing good happens overnight and patience is one of the few things I have, well for tech anyways.
1 Likes, Who?
It's PR stunt paid by Intel again.
They isolated the L1 design and simulated an attack ignoring the rest of the CPUs design/safe guards.
So whilst possible when simulated but so is me drilling through a 6" thick steel plate with my finger under simulation given the right coding
They isolated the L1 design and simulated an attack ignoring the rest of the CPUs design/safe guards.
So whilst possible when simulated but so is me drilling through a 6" thick steel plate with my finger under simulation given the right coding
0 Likes
Quoting: pete910It's PR stunt paid by Intel again.
They isolated the L1 design and simulated an attack ignoring the rest of the CPUs design/safe guards.
So whilst possible when simulated but so is me drilling through a 6" thick steel plate with my finger under simulation given the right coding
oh, there we go, I thought I was fast enough debunking the tinfoil but apparently I wasn't. The paper was done by the same researchers who already "targeted" Intel multiple times and the researchers never claimed AMD CPUs being exploitable either. However, they're research found that the L1d predictor is vulnerable, which can prove useful in future research.
1 Likes, Who?
Philadelphus Mar 8, 2020
Eh, just like the Intel vulnerabilities lately, this is hardly surprising. CPUs nowadays are incredibly complicated systems, and engineers have a limited timeframe to design and test them. Once they're out in the world, however, anyone can spend however much time they like looking for unforeseen interactions and exploits. Of course people are going to find vulnerabilities and exploits in them; it'd be surprising if they didn't.
It's like Hal Clement, the sci-fi author said: an author only has so long to write a book, readers have all the time in the world after it's been published to look for errors. :)
It's like Hal Clement, the sci-fi author said: an author only has so long to write a book, readers have all the time in the world after it's been published to look for errors. :)
0 Likes
Quoting: LeonardKQuoting: pete910It's PR stunt paid by Intel again.
They isolated the L1 design and simulated an attack ignoring the rest of the CPUs design/safe guards.
So whilst possible when simulated but so is me drilling through a 6" thick steel plate with my finger under simulation given the right coding
oh, there we go, I thought I was fast enough debunking the tinfoil but apparently I wasn't. The paper was done by the same researchers who already "targeted" Intel multiple times and the researchers never claimed AMD CPUs being exploitable either. However, they're research found that the L1d predictor is vulnerable, which can prove useful in future research.
I agree but reverse engineering a component then simulating it without knowing that it's correct then missing rest of the CPU/firmware safe guards is misleading.
0 Likes
GustyGhost Mar 11, 2020
Quoting: ajgpOnly 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.
Two things:
1. x86 extensions tend to fall out of patent after 20 years, so a chip designer could theoretically build and sell high performance x86 chips so long as their instruction set matches Intel/AMD cross-licensed instructions up to the year 2000. There would be a lot of missing decode and multi media extensions but it would be doable in theory.
2. The whole problem can be side stepped by rejecting the use of software in which the user is reliant on a proprietor to compile the software. With freely licensed code, software can generally be built and run for any architecture. Proprietary software is the life blood of predatory vendor lock in.
Last edited by GustyGhost on 11 March 2020 at 3:19 am UTC
0 Likes
Quoting: pete910Quoting: LeonardKoh, there we go, I thought I was fast enough debunking the tinfoil but apparently I wasn't. The paper was done by the same researchers who already "targeted" Intel multiple times and the researchers never claimed AMD CPUs being exploitable either. However, they're research found that the L1d predictor is vulnerable, which can prove useful in future research.
I agree but reverse engineering a component then simulating it without knowing that it's correct then missing rest of the CPU/firmware safe guards is misleading.
It's a totally valid approach. We have to remember that this is a *research paper*, not someone claiming "they hacked AMD". They pick one component and anlyse it, they don't "misleadingly leave out". In the paper itself, they also explicitly state the model and attack vector. But one can also guess at how irrelevant the paper is to *systems administrators* by it not being pushed by the researches, there's no big website as with meltdown/spectre/lvi etc.
0 Likes
Quoting: LeonardKQuoting: pete910Quoting: LeonardKoh, there we go, I thought I was fast enough debunking the tinfoil but apparently I wasn't. The paper was done by the same researchers who already "targeted" Intel multiple times and the researchers never claimed AMD CPUs being exploitable either. However, they're research found that the L1d predictor is vulnerable, which can prove useful in future research.
I agree but reverse engineering a component then simulating it without knowing that it's correct then missing rest of the CPU/firmware safe guards is misleading.
It's a totally valid approach. We have to remember that this is a *research paper*, not someone claiming "they hacked AMD". They pick one component and anlyse it, they don't "misleadingly leave out". In the paper itself, they also explicitly state the model and attack vector. But one can also guess at how irrelevant the paper is to *systems administrators* by it not being pushed by the researches, there's no big website as with meltdown/spectre/lvi etc.
I understand it's a valid approach, Their method of analysis is fine on a academic level, In practice it's very flawed due to obvious reasons.
Trouble is it has been mislead as an actual vulnerability/possible exploit when it's not by various media outlets/headlines.
0 Likes
Quoting: pete910Quoting: LeonardKQuoting: pete910Quoting: LeonardKoh, there we go, I thought I was fast enough debunking the tinfoil but apparently I wasn't. The paper was done by the same researchers who already "targeted" Intel multiple times and the researchers never claimed AMD CPUs being exploitable either. However, they're research found that the L1d predictor is vulnerable, which can prove useful in future research.
I agree but reverse engineering a component then simulating it without knowing that it's correct then missing rest of the CPU/firmware safe guards is misleading.
It's a totally valid approach. We have to remember that this is a *research paper*, not someone claiming "they hacked AMD". They pick one component and anlyse it, they don't "misleadingly leave out". In the paper itself, they also explicitly state the model and attack vector. But one can also guess at how irrelevant the paper is to *systems administrators* by it not being pushed by the researches, there's no big website as with meltdown/spectre/lvi etc.
I understand it's a valid approach, Their method of analysis is fine on a academic level, In practice it's very flawed due to obvious reasons.
Trouble is it has been mislead as an actual vulnerability/possible exploit when it's not by various media outlets/headlines.
Sure the coverage was misleading (as almost always in IT-sec), I'm only arguing against the science being flawed or the researches being paid by Intel.
0 Likes
Patreon
PayPal
See more from me