4 ms·

> 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

> 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.
  - kllrnohj 7y ago
    > 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? That was sort of my point, we shouldn't be making that comparison but further up in the comment chain that's exactly what was being done. The paper itself is great and definitely should exist. But it's not a counter-argument to "yet another Intel attack surfaces" either.

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.
- kllrnohj 7y ago
  > 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? That was sort of my point, we shouldn't be making that comparison but further up in the comment chain that's exactly what was being done. The paper itself is great and definitely should exist. But it's not a counter-argument to "yet another Intel attack surfaces" either.