[Cryptography] Speculation considered harmful?

Ray Dillinger bear at sonic.net
Sat Jan 6 18:28:42 EST 2018


If the real impact of this class of attack is as it seems, "we need to
fundamentally redesign our CPUs", then the obvious question is "what is
the best way to achieve the desired result within the now
better-understood design space?"

This has me thinking about different basic architectures with different
approaches to getting a lot of computing done in a short time.

One of them is VLIW, or "Very Long Instruction Word," which exploits
deliberately explicit instruction level parallelism rather than implicit
(speculative) instruction parallelism.  It amounts to having a wide pipe
to instruction memory and loading/executing parallel segments of code
_all_belonging_to_the_same_process_ as though they were single
instructions, explicitly in parallel. Context switching occurs between
VLIW segments, with all cache and register switching done at that time.

VLIW architectures had explicit preloads, which went into a VLIW several
cycles before a cycle that made use of the preloaded data, and
instructions that modern CPUs achieve by means of speculation -
simultaneously updating dozens of weak-ish cores with different
sub-instructions for dozens of VLIW cycles, and then either integrating
the results or "realizing" one by having it write its results to a
shared variable.

It didn't get much tread in the middle '80s and early '90s on account of
the machine code being pretty baffling to humans, and our compilers not
being very efficient at the parallelization task at the time. But to a
first approximation humans no longer look at machine code at all, and
our compiler tech is a hell of a lot better now.  Finally, offloading
the work of figuring out parallelization from the CPU's real-time tasks
means you could run the things while generating significantly less heat
and consuming significantly less power.

So....  I've been thinking, and that's one of my thoughts.

					Bear



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180106/b28ee6d8/attachment.sig>


More information about the cryptography mailing list