We know about short-term measures to mitigate the Meltdown and Spectre vulnerabilities in certain microprocessors where speculative execution has measurable effects on cache timings (mainly patches to microcode, operating systems and any applications containing trust boundaries).

What are the long-term solutions to the problem?

Obvious, simple solutions such as "don't speculate" or "ignore cache when speculating" are unlikely to be acceptable due to the performance considerations that introduced speculation in the first place.

Perhaps speculated instructions could use a separate cache, which is only copied to main cache if the speculation succeeds? If not, why not?

Could processors add privilege information to page table entries, to make Kernel Page Table Isolation automatic (and reduce its performance impact)?

Are there other design changes that improve security without a big performance hit?

  • I saw somewhere suggesting that if some data is loaded to cache due to speculative execution and it ends up not being used, the cache entry should be removed, but it would add extra work to manage the cache.
    – luizfzs
    Jan 19, 2018 at 13:17
  • @luizfzs, I heard something similar; the difficulty is that you then have to "un-evict" whatever that line displaced, or you still have a leak. Jan 19, 2018 at 13:21
  • I think that if you mark the line as not used, it would not leak the speculatively fetched data, since it would be a cache-miss and the data will not be returned. My reasoning might be wrong, though.
    – luizfzs
    Jan 19, 2018 at 13:26
  • The trouble is that if you've brought something into cache, you had to evict something else to make way for it. And an attacker may be able to monitor the data of the evicted line and discover that takes longer to access, thus revealing something about the speculated instructions. It's a much harder attack, but not impossible. Jan 19, 2018 at 13:32
  • 3
    @luizfzs, it's unfortunate that the proof-of-concept demonstration for Spectre used the cache as the side channel: it's got most people fixated on the cache as the vulnerable point, when in fact any speculatively-controllable aspect of the CPU can be used as a side channel.
    – Mark
    Jan 19, 2018 at 21:40

3 Answers 3


Fixing Meltdown is simple: if the CPU is performing speculative execution, don't read data from protected areas of memory. The fact that Meltdown is almost exclusively Intel-only shows that it's a design flaw, rather than an inherent side effect of speculative execution.

Fixing Spectre in the general case is much harder. Spectre is about inducing a program to speculatively malfunction, then observing side effects of that malfunction. You cannot get rid of all the side effects: even if you could roll back all the caches, buffers, tables, and whatnot, there's the simple fact that speculative execution involves speculative execution. Running speculative instructions takes a (somewhat data-controllable) amount of time, which can't be undone short of figuring out time travel.

What can be done is to greatly increase the difficulty of inducing a speculative malfunction. Currently, most CPUs have no concept of "process", and use only part of the address when performing lookups in the branch prediction table. If branch prediction data is tagged to indicate which process it belongs to, or if the branch prediction table is flushed on each context switch, the ability of one program to mis-train the branch predictor's actions for another program are effectively eliminated. Similarly, if branch prediction is performed using the full address, a program can't attack itself (for example, Javascript wouldn't be able to use Spectre break out of a web browser's sandbox).

  • Tagging branch prediction data to indicate a process sounds like a practical idea. I wonder if Intel plans to implement something like that. As for flushing the prediction table on every context switch, I would imagine that would have some severe performance impacts.
    – forest
    Jul 30, 2018 at 2:28

All three attacks use side-channels where speculative execution produced side-effects that can be practically observed.

To prevent this class of attacks, speculative execution circuits will have to be changed to not produce any observable processor state change (apart from the temporary results they produced). For example, the processor can snapshot all caches, buffers and tables before speculative execution and restore them if the branch was not taken. Alternatively, it can prevent the effect from being observed by making access to all cache lines equally slow for the first time after a branch prediction failure for example.

Unfortunately, any fix will mean a big change to current processor designs and methodologies and will probably negate a lot of the benefits of branch prediction and speculative execution.

  • 1
    I would love to see the CPU that can undo the fact that 40 cycles were spent performing a speculative IDIV operation.
    – Mark
    Jan 19, 2018 at 21:41
  • Interesting ideas - but where is a processor going to save these snapshots of cache? That sounds like we'd need 3 or 4 times the area of each cache (or alternatively, for the same area, only have ¼ to ⅓ the amount of effective cache). Users aren't going to like that! Jan 22, 2018 at 8:51
  • The actual implementation will probably be some kind of randomisation in cache line aliasing, so one cannot map back the cache line to an address. Alternatively, a different cache area can be used for speculative execution only and flushed if the speculative results are not committed.
    – billc.cn
    Jan 22, 2018 at 16:03
  • 1
    @billc.cn It doesn't have to involve the cache at all. As Mark said, it could even be done with a speculative IDIV instruction (which takes a variable amount of time based on the operands).
    – forest
    Mar 7, 2018 at 6:31

Well as far as I know, the short-term measures to mitigate the Meltdown and Spectre vulnerabilities in certain microprocessors where speculative execution has measurable effects on cache timings (mainly patches to microcode, operating systems and any applications containing trust boundaries).

So from that I could say that the proper way of preventing ANY informations leak from a CPU/GPU/PSU would be the "Ziploc" paradigm. The ziploc paradigm A.K.A Ziparadignloc, is the only way to prevent such thing as it is properly sealed once sealed.

  • 2
    You probably need to explain what a "Ziploc paradigm" is. I'd not heard of it, and searching the usual places didn't reveal anything. Jan 19, 2018 at 14:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .