4 ms·

The "new" AMD attack depends on lack of already existing spectre mitigations. If I understand correctly, this one is a real new one that works against a correct

by temac 7y ago

The "new" AMD attack depends on lack of already existing spectre mitigations. If I understand correctly, this one is a real new one that works against a correctly patched system.

cosmiccatnap 7y ago
You are correct. No AMD vulnerability is in the same universe as the Intel vulnerabilities from this year alone. Good luck on your new build
- afiori 7y ago
  Curiosity: is this down voted because it is false/exaggerated? As someone that is far from being an expert I would be interested in a counterexample
  - saagarjha 7y ago
    I think the current outlook on this is "the only reason we're not seeing speculative bugs with AMD is because nobody is looking and they're probably more annoying to find", not that they're not there.
    - deleted 7y ago
      [deleted]
paulmd 7y ago
the new AMD attack effectively breaks KASLR (the "metadata" that the attack reveals is page table layouts) and AMD has announced they're not going to patch it. itself it's not a problem but if you pair it with something else it destroys a major line of defense against that something else. AMD is still architecturally vulnerable to some variants of SPECTRE, they just consider it "hard to exploit", but they do recommend you run KASLR to harden against it. Well, so much for that.
- AnthonyMouse 7y ago
  Wasn't KASLR (really KPTI, originally a KASLR hardening technique) a mitigation against Meltdown, which AMD isn't vulnerable to, rather than Spectre?
  - chousuke 7y ago
    As far as I understand it, KASLR is a general hardening technique to shuffle the kernel address space so that it's harder for attackers to use vulnerabilities successfully to attack the kernel. I don't think it's specifically for Meltdown.
    - AnthonyMouse 7y ago
      ASLR is a general technique to try to prevent memory corruption vulnerabilities from being turned into code execution when the attacker can determine the location of already-existing code in memory and use the memory corruption to cause program flow to jump to it. It works pretty well against remote code execution because it's hard for an attacker who can't already execute arbitrary code on your machine to determine the address space layout. In principle it can also be used to protect the kernel against user processes, but that's much harder because a process that can already execute arbitrary user code on the same machine can use a variety of side channel attacks like this to determine the kernel address space layout. KPTI was originally proposed to close some of those side channels, but it's kind of expensive. It only got enabled by default (on Intel) because it also mitigates Meltdown, which is a much worse problem. It also doesn't handle all of the side channels: http://www.cs.ucr.edu/~nael/pubs/micro16.pdf http://www.cs.ucr.edu/~nael/pubs/micro16.pdf Meanwhile, if some kernel code is vulnerable to Spectre (i.e. the Spectre mitigations are not implemented properly), it could allow the attacker to read arbitrary kernel memory. That is obviously very bad, but the ability to read arbitrary kernel memory implies that the attacker can already determine the kernel address space layout, so I'm not sure how KASLR would be helpful in mitigating that.
avianes 7y ago
> The "new" AMD attack depends on lack of already existing spectre mitigations. No, it's a misunderstanding to say that the flaw in the "Take A Way" whitepaper depends on a mechanism already patched. Attack scenarios which are used in the paper to show the feasibility of the 2 new side channels are patched (except the KASLR entropy reduction), but the side-channels themselves are not patched.
- kllrnohj 7y ago
  > but the side-channels themselves are not patched. And might never be patched just like FLUSH+RELOAD never was. And the paper itself even points out that FLUSH+RELOAD is a more applicable attack than Load+Reload is: > Comparison with Flush+Reload. While Flush+Reload invalidates a cache line from the entire cache hierarchy, Load+Reload only evicts the data for the sibling thread from the L1D. Thus, Load+Reload is limited to cross-thread scenarios, while Flush+Reload is applicable to cross-core scenarios too. Collide+Probe is more interesting as it can use virtual address instead of physical address in comparison to Prime+Probe. That may get a microcode update to do a way flush on context switch as part of general Spectre mitigations (just like the branch predictors are), but it can also be handled entirely in software by adjusting how the AES implementation works as the paper also talks about. But fundamentally what these attacks enable are super old & well known, with multiple existing mechanisms that fulfill similar roles. It's why Spectre/Meltdown never focused on the side-channel part of the attack, because it seems to just be assumed side-channels will always exist. And why the paper used existing, documented vulnerabilities to do the exploit side of their PoC, just changing the side-channel used to ex-filtrate the data. Is there something particularly unique or severe about "Take A Way" other than techchrunch's bad reporting of it?
  - avianes 7y ago
    > But fundamentally what these attacks enable are super old & well known, with multiple existing mechanisms that fulfill similar roles. It still has to be published. The article doesn't claim to break all the isolation mechanisms of the processor like Spectre/Meltdown. Why should we compare this paper with Spectre/Meltdown? > Is there something particularly unique or severe about "Take A Way" other than techchrunch's bad reporting of it? Yes, there are at least three things in "Take A Way" which is interesting: - These side-channels are harder to detect because it doesn't require a very intensive use of the cache (no flush / filling all cache ways / etc.). A single collision is enough to evict a targeted cache line. - It allows to set up a covert channel that can transfer up to 588.9 kB/s. - They did a reverse engineering job on a processor mechanism and its undocumented hash function.

by temac 7y ago

The "new" AMD attack depends on lack of already existing spectre mitigations. If I understand correctly, this one is a real new one that works against a correctly patched system.

cosmiccatnap 7y ago

You are correct. No AMD vulnerability is in the same universe as the Intel vulnerabilities from this year alone. Good luck on your new build

afiori 7y ago
Curiosity: is this down voted because it is false/exaggerated? As someone that is far from being an expert I would be interested in a counterexample
- saagarjha 7y ago
  I think the current outlook on this is "the only reason we're not seeing speculative bugs with AMD is because nobody is looking and they're probably more annoying to find", not that they're not there.
  - deleted 7y ago
    [deleted]

paulmd 7y ago

the new AMD attack effectively breaks KASLR (the "metadata" that the attack reveals is page table layouts) and AMD has announced they're not going to patch it. itself it's not a problem but if you pair it with something else it destroys a major line of defense against that something else. AMD is still architecturally vulnerable to some variants of SPECTRE, they just consider it "hard to exploit", but they do recommend you run KASLR to harden against it. Well, so much for that.

AnthonyMouse 7y ago
Wasn't KASLR (really KPTI, originally a KASLR hardening technique) a mitigation against Meltdown, which AMD isn't vulnerable to, rather than Spectre?
- chousuke 7y ago
  As far as I understand it, KASLR is a general hardening technique to shuffle the kernel address space so that it's harder for attackers to use vulnerabilities successfully to attack the kernel. I don't think it's specifically for Meltdown.
  - AnthonyMouse 7y ago
    ASLR is a general technique to try to prevent memory corruption vulnerabilities from being turned into code execution when the attacker can determine the location of already-existing code in memory and use the memory corruption to cause program flow to jump to it. It works pretty well against remote code execution because it's hard for an attacker who can't already execute arbitrary code on your machine to determine the address space layout. In principle it can also be used to protect the kernel against user processes, but that's much harder because a process that can already execute arbitrary user code on the same machine can use a variety of side channel attacks like this to determine the kernel address space layout. KPTI was originally proposed to close some of those side channels, but it's kind of expensive. It only got enabled by default (on Intel) because it also mitigates Meltdown, which is a much worse problem. It also doesn't handle all of the side channels: http://www.cs.ucr.edu/~nael/pubs/micro16.pdf http://www.cs.ucr.edu/~nael/pubs/micro16.pdf Meanwhile, if some kernel code is vulnerable to Spectre (i.e. the Spectre mitigations are not implemented properly), it could allow the attacker to read arbitrary kernel memory. That is obviously very bad, but the ability to read arbitrary kernel memory implies that the attacker can already determine the kernel address space layout, so I'm not sure how KASLR would be helpful in mitigating that.

avianes 7y ago

> The "new" AMD attack depends on lack of already existing spectre mitigations. No, it's a misunderstanding to say that the flaw in the "Take A Way" whitepaper depends on a mechanism already patched. Attack scenarios which are used in the paper to show the feasibility of the 2 new side channels are patched (except the KASLR entropy reduction), but the side-channels themselves are not patched.

kllrnohj 7y ago
> but the side-channels themselves are not patched. And might never be patched just like FLUSH+RELOAD never was. And the paper itself even points out that FLUSH+RELOAD is a more applicable attack than Load+Reload is: > Comparison with Flush+Reload. While Flush+Reload invalidates a cache line from the entire cache hierarchy, Load+Reload only evicts the data for the sibling thread from the L1D. Thus, Load+Reload is limited to cross-thread scenarios, while Flush+Reload is applicable to cross-core scenarios too. Collide+Probe is more interesting as it can use virtual address instead of physical address in comparison to Prime+Probe. That may get a microcode update to do a way flush on context switch as part of general Spectre mitigations (just like the branch predictors are), but it can also be handled entirely in software by adjusting how the AES implementation works as the paper also talks about. But fundamentally what these attacks enable are super old & well known, with multiple existing mechanisms that fulfill similar roles. It's why Spectre/Meltdown never focused on the side-channel part of the attack, because it seems to just be assumed side-channels will always exist. And why the paper used existing, documented vulnerabilities to do the exploit side of their PoC, just changing the side-channel used to ex-filtrate the data. Is there something particularly unique or severe about "Take A Way" other than techchrunch's bad reporting of it?
- avianes 7y ago
  > But fundamentally what these attacks enable are super old & well known, with multiple existing mechanisms that fulfill similar roles. It still has to be published. The article doesn't claim to break all the isolation mechanisms of the processor like Spectre/Meltdown. Why should we compare this paper with Spectre/Meltdown? > Is there something particularly unique or severe about "Take A Way" other than techchrunch's bad reporting of it? Yes, there are at least three things in "Take A Way" which is interesting: - These side-channels are harder to detect because it doesn't require a very intensive use of the cache (no flush / filling all cache ways / etc.). A single collision is enough to evict a targeted cache line. - It allows to set up a covert channel that can transfer up to 588.9 kB/s. - They did a reverse engineering job on a processor mechanism and its undocumented hash function.