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?

Improve this question
8
  • 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
    Commented 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.
    – Toby Speight
    Commented 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
    Commented Jan 19, 2018 at 13:26
  • 5
    @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
    Commented Jan 19, 2018 at 21:40
  • 1
    I did not notice this question at the time. Probably distracted and enraged by Spectre and particularly Meltdown. Late comments: (1) As @Mark says, any shared state modified by speculation may be a Speculative side channel. In general, any shared state can be a side channel. (2) To solve side channel attacks, you partition in time and/or partition in space. Partition in space = don't share it. Partition in time = flush it and ensure that the time to flush is constant or possibly randomized. AFAIK these are the only ways of solving covert channel problems.
    – Krazy Glew
    Commented Jul 8 at 17:06

4 Answers 4

Reset to default
8

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

Improve this answer
6
  • 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
    Commented Jul 30, 2018 at 2:28
  • Late: agreed "speculation should not read protected areas of memory". Conjecture: Starting with the Intel P4 / Willamette processor, the L1 or L0 data cache was accessed and execution using that data started EVEN BEFORE YOU KNEW IT WAS A CACHE HIT. Cache way predictor, etc.. IIRC the address match hit/miss & many cycles later, like 7, with several dependent instructions. Full Meltdown speculatively accesses cache misses. By then you must done the TLB lookup, so you should be able to prevent speculative cache misses to protect the data. But "Meltdown cache hit" might still happen.
    – Krazy Glew
    Commented Jul 8 at 17:14
  • IMHO "Meltdown cache miss" did not need to occur, since the processor had probably done the virtual to physical translation, and hence knew if the page was protected. But doesn't help for "Meltdown cache hit", since several speculative instructions might have executed using the privileged data, on a deeply pipelined machine. I'm guessing that somebody thought it was simpler to stop all speculative execution at retirement, rather than have a separate mechanism to prevent speculative execution past page-faults.
    – Krazy Glew
    Commented Jul 8 at 17:17
  • Another possible mechanism: store-to-load-forwarding, based on virtual address or forwarding predictors. Mitigation: carrying privileged domain STLF buffer is probably too expensive/slow. It is probably reasonable to flush the STLF buffer at privilege boundaries.
    – Krazy Glew
    Commented Jul 8 at 17:27
  • AFAIK no current processors speculate past system calls. Although if they did system calls would be cheaper, and it would probably encourage software to be more secure. But anyway, STLF "flushing" after missed speculation returning to different privilege level is probably reasonable. Flushing after system call return would be unfortunately hard to avoid, although it could be left up to software. // "Flushing" probably would just be a bulk clear of some valid bits.
    – Krazy Glew
    Commented Jul 8 at 17:30
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.

Improve this answer
5
  • 1
    I would love to see the CPU that can undo the fact that 40 cycles were spent performing a speculative IDIV operation.
    – Mark
    Commented 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!
    – Toby Speight
    Commented 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
    Commented 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
    Commented Mar 7, 2018 at 6:31
  • @Mark: Being capable of doing 40 cycles of useful work after a speculative IDIV is pretty common nowadays. Say 4 wide: 4*40=160 NOPs to fill your instruction window. Instruction windows of 256 are fairly common nowadays, and were anticipated even in 2018. Even in Intel P6 1996 you could execute a chain of dependent cache misses that would occupy all the time in the shadow of IDIV. it would not fill the reorder buffer, but it would fill the reservation stations. // Oh wait, you are talking about undoing micro architectural side effects. Not likely I agree
    – Krazy Glew
    Commented Jul 8 at 17:36
1

The ARM processors in a iPhone can be put into a mode where each processor instruction always takes the longest possible time. For example a divide instruction with data dependent execution time would always take the same time in this mode.

A processor could have a mode that doesnt allow speculative execution at all (but none has afaik). This would reduce performance, but only for the crypto operation. You’d still have to watch for data-dependent non-speculative memory access.

Improve this answer
-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.

Improve this answer
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
    Commented 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 .