AMD just recently had a 'Take A Way' security issue for their CPUs disclosed

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

So if it is just a new way to exploit previously known speculative execution vulnerabilitys, is it really a new attack?

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/

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.

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.

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?

Can't wait for open source CPUs to become more popular and powerful.

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.

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).

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

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.

Quoting: ajgp

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.

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.

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

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.

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. :)

Quoting: LeonardK

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.

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.

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

Quoting: pete910

Quoting: 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.

Quoting: LeonardK

Quoting: pete910

Quoting: 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.

Quoting: pete910

Quoting: LeonardK

Quoting: pete910

Quoting: 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.