As expected, silence on Spectre v1. But nice job @arstechnica being explicit that the microcode fixes are for Spectre v2.https://twitter.com/DrPizza/status/966389985510416385 …
-
-
Just echoing the paper "Where Meltdown and Spectre arise by polluting the cache during speculation, MeltdownPrime and SpectrePrime are caused by write requests being sent out speculatively in a system that uses an invalidation-based coherence protocol." https://arxiv.org/pdf/1802.03802.pdf …
-
That paper is using the exact same speculative execution, it's just doing the inverse cache side channel (one line is fast, because it's been fetched, rather than slow, because it's been evicted)
-
Not sure what you mean ... novel in that they are 2-core attacks which leverage the cache line invalidation mechanism in modern cache coherence protocols. ... Prime attacks exploit invalidation-based coherence protocols ... same level of precision as a Flush+Reload attack
-
I mean that they're using the exact same speculative execution, just slightly different cache side channels. The original papers used flush+reload (which makes one loaded line fast), this is using prime+probe (which makes one invalidated line slow).
-
In both cases, if you prevent speculative loads (e.g. with x86 lfence, ARM csdb), the only cache lines that get loaded or invalidated are those that are actually used.
-
Observable cache effects of the path-actually-taken are a problem for cryptography, but they're not a problem for speculative execution side channels.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.