9

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?

Toby Speight
  • 1,214
  • 9
  • 17
  • 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 '18 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. – Toby Speight Jan 19 '18 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 '18 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. – Toby Speight Jan 19 '18 at 13:32
  • That makes sense. From the top of my mind, I can't come with ideas to leverage that but there are, for sure. – luizfzs Jan 19 '18 at 13:41
  • Copy cache would probably be even slower than disabling speculative execution... – sunny-lan Jan 19 '18 at 16:50
  • 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 '18 at 21:40

3 Answers3

6

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).

Mark
  • 34,390
  • 9
  • 85
  • 134
  • 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 '18 at 02:28
1

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.

billc.cn
  • 3,852
  • 1
  • 16
  • 24
  • 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 '18 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! – Toby Speight Jan 22 '18 at 08: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 '18 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 07 '18 at 06:31
-2

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.

Jew Shew
  • 1
  • 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. – Toby Speight Jan 19 '18 at 14:24