This is legal/PR mumbo jumbo. Nowhere in that statement does AMD say they have patched this. instead, the make vague reference to previously-patched vulnerabilities that are NOT the vuln in question.
Also, they say they 'believe' it isn't new, and that word is used for a reason - it isn't legally binding. It is a lot different than saying "It isn't new."
Finally, the advice they give is akin to giving general advice for a Ford vehicle: "Change the oil every 3500 miles."
Generalized statements that mean nothing.
This looks to be an intentionally obfuscated response.
AMD does not "patch" Spectre. Spectre has to be patched by developers, who execute untrusted code within the trusted address space (e.g. browser and OS developers). I am taking AMD press release to mean, that this "attack" — note how researchers consistently use this word instead of "vulnerability" — is simply proof-of-concept for well known Spectre flaws or possibly even expected behavior of the CPU cache (in non-SMT case).
Many Spectre-type flaws are essentially about an OS process reading/writing it's own memory — which it is naturally expected to have access to. Of course, browser developers weren't prepared for that, but they also were not prepared for gzip-bombs...
I assume, that mitigations [1] suggested by AMD in 2018 are sufficient to protect against this (and all other) Spectre flavors on AMD CPUs, in which case there is really nothing new going on here.
I'm pretty sure the issue with Spectre/Meltdown is about an OS process reading other processes' (or kernel) memory. These are fundamentally chip issues, not developer issues.
No, Spectre is always about reading your own memory. Your link is about exploiting MDS aka Zombieload — a separate hyper-threading vulnerability, specific to Intel CPUs.
The issue with Meltdown is about an OS process reading other processes' (or kernel) memory - this is caused by the CPU not enforcing its protection boundaries properly and is mitigated by CPU microcode or firmware updates.
The issue with Spectre is about an OS process (or kernel) reading its own memory - this is why in contrast to Meltdown it can't be fully fixed by CPU microcode or firmware updates, it requires mitigation in any code that enforces security boundaries, such as kernels or sandboxing VMs.
On the contrary, I think that first quote by AMD is very clear:
> ... 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.
They are explaining why they don't believe it is new, it's because they don't use a new speculative execution. AND if all the old ones were patched, all a customer would have to do to protect themselves is keep their system up to date.
Sure the PR statement isn't legally binding (as nearly all PR statements are designed), but they left a very clear explanation. It does not at all appear intended to mislead.
> Also, they say they 'believe' it isn't new, and that word is used for a reason - it isn't legally binding. It is a lot different than saying "It isn't new."
Yes, PR is covering their butts with believe. This is a response PR; it needs to go out within a couple of days tops, but within 24 hours of the report is best. That's not enough time to confirm the new claims or that the speculative claims are existing. This PR say, yes, we know about this; we triaged it, and we'll get back to you later; please stop calling about it.
Expect a more thorough response, with more certainty in probably a few weeks; although, I dunno AMDs usual timelines on this sort of thing.
Why would they need a quick PR response when this was disclosed months ago already? Wouldn't they have put in time to verify in that period, add me as this was disclosed responsibly?
The author does not claim that these attacks currently allow to break all processor securities.
He just points out that two new side channels are possible by exploiting AMD optimizations then it demonstrates their feasibility on already known and fixed attacks.
But beware, what is already known/fixed and requires to disable patches are the attack scenarios and not the 2 new side-channels described in the whitepaper!
Maybe there are unknown scenarios where they could be used, who knows?
Finally he suggests some countermeasures.
So, no, it's not a nothingburger at all.
It is a detailed research work that anticipates a potential issue, suggests solutions and explains undocumented processor features.
The information in the article is incorrect. The PDK gives more performance OR more power, but not both. Other reporters have this correct, while this article is incorrect.
The article does have an incredibly narrow focus. It's as if the author doesn't know AMD exists, when in fact AMD is a far far larger threat to Intel due to its chips native support of the x86 instruction set.
Intel used to keep less important products, like chipsets, on trailing nodes (right now, that's 22nm). Now the company is fabbing the chipsets on 14nm, too. That's mainly because of the late move to 10nm. Intel's processors SHOULD be on 10nm, but they aren't, so chipsets are eating into 14nm production capacity. Intel has to create one chipset for each processor produced (in most cases), so this adds up to a lot of chips.
Also, they say they 'believe' it isn't new, and that word is used for a reason - it isn't legally binding. It is a lot different than saying "It isn't new."
Finally, the advice they give is akin to giving general advice for a Ford vehicle: "Change the oil every 3500 miles."
Generalized statements that mean nothing.
This looks to be an intentionally obfuscated response.