[Cryptography] Speculation considered harmful?

Henry Baker hbaker1 at pipeline.com
Fri Jan 5 11:41:16 EST 2018


At 08:32 PM 1/4/2018, Tony Arcieri wrote:
>I think RISC-V makes for an interesting sidebar...
>
>I have seen a lot of (mostly joking) calls for an earlier time when CPUs didn't do speculative execution (often pointing to '60s era VAX systems or what have you).
>
>Most RISC-V CPUs that presently exist today do not implement speculation.  This is mostly just because for the most part RISC-V is a "puny core" and where people are building larger RISC-V chips they're taking the "swarm of puny cores" approach, e.g. this 4096-core CPU:
>
><https://fuse.wikichip.org/news/686/esperanto-exits-stealth-mode-aims-at-ai-with-a-4096-core-7nm-risc-v-monster/>https<https://fuse.wikichip.org/news/686/esperanto-exits-stealth-mode-aims-at-ai-with-a-4096-core-7nm-risc-v-monster/>://fuse.wikichip.org/news/686/esperanto-exits-stealth-mode-aims-at-ai-with-a-4096-core-7nm-risc-v-monster/
>
>That said, adding speculative execution features to RISC-V is presently an open research area (perhaps some companies have shipped RISC-V CPUs with these features, but I am not presently aware of any)
>
>In 20/20 hindsight of this whole debacle, I am curious if, along with memory protections available in RISC-V CPUs such as an "every word tagged" memory architecture, RISC-V can strategically eliminate this entire bugclass, e.g. ensuring privilege checks are always synchronous because the only physical path to the memory demands it.  As far as I can tell it has both a great foundation and is in the perfect place to solve these problems correctly in a clean-room implementation.
>
>The "swarm of puny cores" approach is a bad fit for a lot of problem domains, so I'm curious to see if RISC-V implementations can evolve into something a bit closer to what we'd use for typical "business logic"-heavy server workloads.

IBM chased instruction pipelining with the 360 Model 91, but then threw in the towel.

Caches were a heck of a lot cheaper and easier to debug than fancy instruction pipelining.

But caching on multiprogramming machines will *always* leak information.

In fact, *multiprogramming* will always leak information.

Example: If I'm a venture capitalist who utilizes an outside law firm to do deals, I suddenly notice that my law firm goes radio silent from time to time.  This "radio silence" leaks information to me.

1.  The law firm could be hard at work on a competitor's deal, so they don't have time to work on my deal.

2.  (Even worse) The law firm has developed a *conflict of interest* and can't work with me until it gets resolved.

If I want, I can additionally probe the law firm myself, or even better, have a third party probe the law firm with various requests for service which will reveal additional information about whether any particular lawyer is busy, or what is the nature of the conflict of interest.

These scenarios translate directly into HW analogies within a computer architecture.

(Spouses/lovers utilize the same techniques to discover "two-timing"; it's difficult to be 2 places at once, or to fully focus on multiple lovers.)



More information about the cryptography mailing list