5 ms·

It can mostly be fixed by making sure aborted speculative execution has no side effects. I think this is doable by adding a buffer to store cache entries evict

by devit 9y ago

It can mostly be fixed by making sure aborted speculative execution has no side effects. I think this is doable by adding a buffer to store cache entries evicted by speculative execution, so they can be put back, and a log of new cache entries, so they can be removed Also, the abort process itself needs to take a constant amount of time out of the critical path to avoid leaking info via timing (the timing then only depends on how fast the CPU determines it speculated wrong, but that doesn't depend on the speculated code). EDIT: Hyperthreading also needs to be handled somehow, which other than disabling it might require adding a per-thread "L0" cache and using that exclusively for speculatively executed code. There is still the problem of theoretical plain timing attacks on normally executed code though, but that's unrelated. Making sure that the indirect branch predictor only makes predictions when the source address fully matches would be nice as well (although theoretically not required if there are no side effects).

cesarb 9y ago
I don't think undoing all cache changes is enough, since it went to memory it generated memory bus traffic, which could be observed by another core (as extra latency). And speaking of another core, the cacheline might have come from another core, which could observe the effect on its own cache, even if it's later put back.
- rphlx 9y ago
  Yes. I doubt this will be what actually happens, but perhaps the safest fix is to remove speculative execution in its entirety, increasing clock frequency and/or core count to mitigate the resulting performance loss by as much as possible.
zakk 9y ago
> It can mostly be fixed by making sure aborted speculative execution has no side effects. Not an expert, but if speculative execution has no side effects, not even on timing, then you might as well disable it. Speculative execution is meant to speed up computations.

by devit 9y ago

cesarb 9y ago

I don't think undoing all cache changes is enough, since it went to memory it generated memory bus traffic, which could be observed by another core (as extra latency). And speaking of another core, the cacheline might have come from another core, which could observe the effect on its own cache, even if it's later put back.

rphlx 9y ago
Yes. I doubt this will be what actually happens, but perhaps the safest fix is to remove speculative execution in its entirety, increasing clock frequency and/or core count to mitigate the resulting performance loss by as much as possible.

zakk 9y ago

> It can mostly be fixed by making sure aborted speculative execution has no side effects. Not an expert, but if speculative execution has no side effects, not even on timing, then you might as well disable it. Speculative execution is meant to speed up computations.