4 ms·

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 vulnerabili

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.

altfredd 7y ago
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. 1: https://developer.amd.com/wp-content/resources/90343-B_SoftwareTechniquesforManagingSpeculation_WP_7-18Update_FNL.pdf https://developer.amd.com/wp-content/resources/90343-B_Softw...
- fractaled 7y ago
  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. See https://googleprojectzero.blogspot.com/2020/02/escaping-chrome-sandbox-with-ridl.html https://googleprojectzero.blogspot.com/2020/02/escaping-chro....
  - loeg 7y ago
    This is a fantastic link, thanks for sharing.
  - altfredd 7y ago
    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_why_of_y 7y ago
    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.
- UncleMeat 7y ago
  There’s about five major spectre classes at this point and they have different mitigation’s. Some are done in the os. Some are done in hardware.
lettergram 7y ago
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.
toast0 7y ago
> 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.
- nevi-me 7y ago
  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?
  - deleted 7y ago
    [deleted]
CriticalCathed 7y ago
I disagree. Spectre vulnerabilities are not new. They didn't make a factual error in their reply.
philjohn 7y ago
It requires Spectre mitigations to be disabled, full stop. So it's a nothingburger.
- avianes 7y ago
  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.

altfredd 7y ago

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. 1: https://developer.amd.com/wp-content/resources/90343-B_SoftwareTechniquesforManagingSpeculation_WP_7-18Update_FNL.pdf https://developer.amd.com/wp-content/resources/90343-B_Softw...

fractaled 7y ago
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. See https://googleprojectzero.blogspot.com/2020/02/escaping-chrome-sandbox-with-ridl.html https://googleprojectzero.blogspot.com/2020/02/escaping-chro....
- loeg 7y ago
  This is a fantastic link, thanks for sharing.
- altfredd 7y ago
  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_why_of_y 7y ago
  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.
UncleMeat 7y ago
There’s about five major spectre classes at this point and they have different mitigation’s. Some are done in the os. Some are done in hardware.

lettergram 7y ago

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.

toast0 7y ago

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

nevi-me 7y ago
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?
- deleted 7y ago
  [deleted]

CriticalCathed 7y ago

I disagree. Spectre vulnerabilities are not new. They didn't make a factual error in their reply.

philjohn 7y ago

It requires Spectre mitigations to be disabled, full stop. So it's a nothingburger.

avianes 7y ago
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.