[Cryptography] Speculation considered harmful?

[Tom Mitchell]

On Sat, Jan 6, 2018 at 3:28 PM, Ray Dillinger <bear at sonic.net> wrote:

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

> One of them is VLIW, or "Very Long Instruction Word," which exploits
> deliberately explicit instruction level parallelism rather than implicit
> (speculative) instruction parallelism.
>
.....
Perhaps think pipeline more than parallel.

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.
>
....
The compilers at SGI were decent... and the engineers looked
hard at the VLIW world and found it brutal.  The Itanium was
VLIW and used in an SGI machine.  There was also a project at
Transmeta.   The Itanium hardware was slower than expected  and buggy.
The compiler software framework changes to address optimization
for classic and VLIW machines and more was not well received  then in
the open source world.  The entire SGI framework was later put out
as open source and can be found by looking for PATHSCALE EKO COMPILER SUITE™
and also looking on the AMD site.  EKO is a bit arrogant "Every Known
Optimization"
but as optimizing compilers go it is a good one and has pulled gcc, LLVM -
clang,
Intel,  Green Hills and other compilers forward a lot.
The AMD compilers vs Intel compiler games are interesting some will recall
"Intel's compiler doesn't have specific "scheduling" modes for AMD, VIA or
Cyrix CPUs
(remember them?), only for Intel products. The CPUID instruction
(introduced in the Pentium)
fills several registers with information about the CPU's make, model name
and capabilities."  <-- reddit Feb 2016
The interesting bit is scheduling modes....

The internals of many processors today are RISC with a microcode
plus hardwired instruction translation from x86* to internal RISC.
The internal RISC and the associated microcode updates are involved
in the current  mitigation efforts.   Early performance measures are showing
better results than might be expected from historic ABI/API  space and
might be microcode assisted.
A risk with microcode updates is that a sufficiently clever intruder
could roll back or modify micro code to reopen or open new bugs.
I never looked at how microcode gets pushed into the part so
hacking it could be easy or hard.

Microsoft is pushing updates very aggressively on Windows10.
That might make it harder for hackers to develop and test
hacks on Win10 ;-)   even if the common Win10 user could care
less about side channel hacks inside his home behind a firewall.

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


You might be on the right path.   VLIW can have deep pipelines
and pipelining + optimization poked at with hand coded ASM seems
to be the method at hand for some of these attacks.

Of interest some old SGI hardware had branch delay slot bug that
required the kernel to inspect the binary and preload paged.  Should the
branch delay code trigger a fault things got messy so the kernel checked
and made sure there was no fault generated.     Binary objects
were also edited by the system to not have a fault at a page boundary
by the runtime link loader and editor.
This is public now see the MIPS R4400 errata...
ftp://ftp.sgi.com/sgi/doc/R4400/R4400_buglist/r4400_2.0_3.0_MC_errata.ps



-- 
  T o m    M i t c h e l l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180109/afa19a9f/attachment.html>