[Cryptography] Speculation considered harmful?

[Will Yager]

On Sat, Jan 6, 2018 at 12:49 AM, Howard Chu <hyc at symas.com> wrote:

>   Eh. In the context of Spectre, the CPU knows which cachelines it loaded in a speculative fetch. It should simply mark them invalid

I do not believe this solves the issue. You aren’t actually reading the contents of the the cache that was loaded during speculative execution; you are using cache behavior as an oracle into whatever happened during speculative execution. A cache line getting marked as invalid is entirely sufficient to leak information from the speculative phase.

You run a speculation widget that does some privileged read, and based on the result of that privileged read you either do or don’t load a value that you know will flush a cache line currently caching data in your process’s address space. After the speculative widget runs, you time a read to the data in your own address space. If it’s slow, the cache line got flushed. If it’s fast, it didn’t. One bit leaked.

There are two approaches that I think would actually solve the issue here.

1. Reset *entire* CPU state (cache, branch predictor state, etc.) to the way it  was before speculation upon a rollback. This would probably either be implemented by having redundant copies of the entire state for every simultaneously supported speculative branch ($$$ and would cap the number of simultaneous speculation much lower than it is now) or keeping a buffer tracking state changes that only gets its tip removed when the corresponding instruction is retired from the reorder buffer ($$, probably slow).

2. Have separate CPU states (cache, branch predictor, etc.) for every security context. You would probably want to "just" have two or three and use them in an LRU fashion, so at least within a given process you can still have the speed benefit of almost-free context switches to kernel. This isn’t actually a full solution, and is still theoretically exploitable depending on what the kernel API looks like, but makes it harder.

There may be other timing channels depending on the OoO implementation (e.g. if you could speculatively gum up the functional units and prevent the speculative dependency from being resolved), but I think these suggestions would at least help to mitigate the (retrospectively) obvious cache-oracle vulnerabilities.

—Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180106/546ae257/attachment.html>