[Cryptography] Speculation re Intel HW cockup; reqs. OS rewrites & slow execution

Nico Williams nico at cryptonector.com
Thu Jan 4 20:06:16 EST 2018


On Thu, Jan 04, 2018 at 02:23:00PM -0800, Henry Baker wrote:
> At 01:32 PM 1/4/2018, jamesd at echeque.com wrote:
> >The fix is not to abandon speculative execution, but to do it right,
> >and chances are that doing it right is going to be faster and more
> >efficient, not slower and less efficient.
> 
> OK, I'll bite.
> 
> How would you do speculative execution "right" ?

I don't see how.  Perhaps jamesd was... speculating.

Speculative execution is necessarily side-effect-having by its potential
cache thrashing impact and ability to be impacted by cache thrashing.
This necessarily creates side-channels.  It seems unavoidable except by
having sandboxed caches, but that's probably not an option for many
reasons (including power consumption).

Facing pressure on the cache front I think CPU designers might
reconsider the UltraSPARC T-n approach of adding more execution units to
compensate for slow memory.  UltraSPARC was a last gasp of a dying
architecture, but the idea behind it might actually work better now.  Of
course, this approach is predicated on software being able to take
advantage of it, but for cloud kit it makes a lot of sense.

I think we'll see a few trends from this:

 - more programmer control over speculation
   (hardly a panacea, but better than nothing)

 - less speculation / slower systems

 - a push for faster RAM?
   (are there technologies on deck that could deliver fast RAM?)

 - more HW threads to compensate for smaller caches, less sharing,
   slower HW threads
   (was the UltraSPAC T series on the right track?)

 - for smartphones a less cache sharing but also less concurrency and/or
   slower app switching

But I'm just speculatin' here!


More information about the cryptography mailing list