2

There are a lot of patches released to fix the recently found Spectre and Meltdown security vulnerability. However they all do this (to my understanding) by disabling usage of certain functionality on the cpu.

So I am wondering if the (predictive) features that are being disabled are likely to come back for the next generation of processors?

What design changes in the cpu architecture need to be made? Can the same predictive algorithms still be used in the future or do they need to be adapted?

I'm looking for a technical explanation what options exist to restore the pre-patch performance and make the functionality secure.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
vincent
  • 1,953
  • 3
  • 18
  • 24
  • 1
    IDK how to solve Spectre, but Meltdown is pretty easy to mitigate with microarchitectural changes. I already wrote this up as part of [Why are AMD processors not/less vulnerable to Meltdown and Spectre?](https://security.stackexchange.com/questions/177100/why-are-amd-processors-not-less-vulnerable-to-meltdown-and-spectre), and [Would buffering cache changes prevent Meltdown? Ask Question](https://stackoverflow.com/questions/48196449/would-buffering-cache-changes-prevent-meltdown/48201056#48201056) (answer: it would partially solve Spectre; Meltdown is easier). – Peter Cordes Jan 13 '18 at 17:40

1 Answers1

0

I suppose it can be fixed by an extra tag (speculation id) in the cache entry that tell if the cached value was brought in by speculation. When reading (external to cpu) an entry with this tag set , the cache entry is invisible (skipped). When the speculation is selected for execution (aka. not discarded), the tag is cleared (for this speculation id). To me it sounds fixable in a week, but then l'm only a software developer, not a cpu designer:-)

Edit: if I understand comments correctly, the above is not sufficient. We need a duplicate L1 cache to also prevent eviction detection.

osexpert
  • 485
  • 1
  • 6
  • 18
  • 2
    The side channel is through cache block placement and replacement. With typical modulo 2 indexing, any block replaced (detected by slower loading caused by a cache miss) will have matching address bits for the index (revealing what those bits for the speculative access were). A victim cache with the same latency as normal L1 accesses would remove the *L1 latency* information channel (appropriate replacement policies making it seem the speculative accesses never happened). –  Jan 15 '18 at 01:39
  • All loads happens speculatively in modern OoO CPUs. It's usually verified (at retirement) to be correct speculation. So the cache bit flip would have to happen at retirement, when that line isn't otherwise being accessed. Or have mispredict-recovery evict lines that were loaded by mis-speculation. But still this only blocks the flush+read cache-timing side-channel. It doesn't block the opposite: prefetch+read to look for a line that was *evicted* by a speculative load. @Paul's suggestion of a victim cache checked in parallel with L1D could stop both side-channels. – Peter Cordes Jan 15 '18 at 02:17
  • 1
    But neither one can stop ALU port-pressure attacks, where the side-channel is timing how fast a loop runs, and the branch-target injection is used to run something that uses different ALU ports depending on the secret data, instead of to load cache. Related: see my answer on [Would buffering cache changes prevent Meltdown?](https://stackoverflow.com/questions/48196449/would-buffering-cache-changes-prevent-meltdown) where I discussed cache tag bits in more detail, and the ALU side channel (which @PaulA.Clayton's victim-cache doesn't solve either). But ALU-timing is less reliable, so it helps. – Peter Cordes Jan 15 '18 at 02:21