When people slam CPU manufacturers for Spectre, remember: Customers demanded speed doubling on legacy code, CPU vendors bent over backwards to accomodate programmers that did not want to learn parallelism.
-
-
Show me. And performance needed for better energy usage, doing more work.
-
Naive approach which likely works (but needs verification): never fetch cache lines speculatively, only speculate with already-in-cache data.
-
You said minimal performance impact. That won't be true. Hiding latency of cache miss by speculating on addresses crucial
-
Tagging cache units with branch IDs and flush as branches become invalid?
-
Flushing is pointless because the speculative load will invalidate the attackers cache line anyway, letting her know which line was loaded. We need a hidden cache that can somehow be made 'visible' when a speculated branch is taken. ARM spec allows hidden cache levels for e.g.
-
I think it's also possible to speculatively fetch to visible cache as long as the address to fetch is a retired result, not speculative, but not 100% sure.
-
It's definitely better than completely giving up on speculation, although I believe that was a necessary first step. The approach of putting in speculation barriers seems kinda naive though given the amount of understanding the average dev has even of memory barriers.
-
Absolutely. Any approach that requires work by the programmer or compiler is fundamentally bogus.
- 12 more replies
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.