No for 3 reasons:measuring L3 and memory latencies would be error prone given how close they are and I don't think there are instructions to specifically load to L3 to do a flush+reload. Also, evicting from L3 is *way* harder.
-
-
Replying to @siddhesh_p @RichFelker and
Paging
@cperciva who did exactly that to attack AES.2 replies 0 retweets 0 likes -
-
-
Replying to @siddhesh_p @WatsonLadd and
Hmm so it looks like it is feasible to do a side channel attack on the last level of cache. ARM spec does not specify how CPUs handle flushing in hidden cache levels, but assuming it still leaves a channel to snoop on, a parallel speculative cache seems like the best way to go
1 reply 0 retweets 1 like -
Replying to @siddhesh_p @WatsonLadd and
I'll probably take a while to grok it's feasibility in the speculative execution use case, but I suppose the safer assumption is that it's doable.
1 reply 0 retweets 0 likes -
Replying to @siddhesh_p @WatsonLadd and
Yes. I think this means disabling speculative fetch (L1 cache miss) for non-retired address operands is necessary for a fix. Sufficient?
1 reply 0 retweets 0 likes -
Replying to @RichFelker @WatsonLadd and
That seems sufficient. The branch ought to have been taken at retire.
1 reply 0 retweets 1 like -
Replying to @siddhesh_p @WatsonLadd and
Actually I worry it's not sufficient with some branch prediction especially indirect...
1 reply 0 retweets 0 likes -
Replying to @RichFelker @siddhesh_p and
Think case where cpu predicts call to function taking ptr but you're really calling function with integer arg under attacker control.
2 replies 0 retweets 0 likes
Disappointing but my guess is that you just have to disable all speculative fetch. At least all future cpus should give an MSR to do that for users who need strong guarantee or don't care about perf loss under heavy L1 misses.
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.