<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jan 6, 2018 at 3:28 PM, Ray Dillinger <span dir="ltr"><<a href="mailto:bear@sonic.net" target="_blank">bear@sonic.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
If the real impact of this class of attack is as it seems, "we need to<br>
fundamentally redesign our CPUs", then the obvious question is "what is<br>
the best way<br></blockquote><div>....</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
One of them is VLIW, or "Very Long Instruction Word," which exploits<br>
deliberately explicit instruction level parallelism rather than implicit<br>
(speculative) instruction parallelism.<br></blockquote><div>.....</div><div>Perhaps think pipeline more than parallel. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It didn't get much tread in the middle '80s and early '90s on account of<br>
the machine code being pretty baffling to humans, and our compilers not<br>
being very efficient at the parallelization task at the time.<br></blockquote><div>....</div><div>The compilers at SGI were decent... and the engineers looked</div><div>hard at the VLIW world and found it brutal.  The Itanium was <br>VLIW and used in an SGI machine.  There was also a project at </div><div>Transmeta.   The Itanium hardware was slower than expected  and buggy.   <br>The compiler software framework changes to address optimization</div><div>for classic and VLIW machines and more was not well received  then in </div><div>the open source world.  The entire SGI framework was later put out<br>as open source and can be found by looking for PATHSCALE EKO COMPILER SUITE™<br>and also looking on the AMD site.  EKO is a bit arrogant "Every Known Optimization"<br>but as optimizing compilers go it is a good one and has pulled gcc, LLVM - clang, <br>Intel,  Green Hills and other compilers forward a lot.  <br>The AMD compilers vs Intel compiler games are interesting some will recall<br>"Intel's compiler doesn't have specific "scheduling" modes for AMD, VIA or Cyrix CPUs </div><div>(remember them?), only for Intel products. The CPUID instruction (introduced in the Pentium) </div><div>fills several registers with information about the CPU's make, model name and capabilities."  <-- reddit Feb 2016<br>The interesting bit is scheduling modes....</div><div><br>The internals of many processors today are RISC with a microcode</div><div>plus hardwired instruction translation from x86* to internal RISC.<br>The internal RISC and the associated microcode updates are involved</div><div>in the current  mitigation efforts.   Early performance measures are showing</div><div>better results than might be expected from historic ABI/API  space and</div><div>might be microcode assisted. <br>A risk with microcode updates is that a sufficiently clever intruder<br>could roll back or modify micro code to reopen or open new bugs.<br>I never looked at how microcode gets pushed into the part so<br>hacking it could be easy or hard.  <br><br>Microsoft is pushing updates very aggressively on Windows10.<br>That might make it harder for hackers to develop and test <br>hacks on Win10 ;-)   even if the common Win10 user could care</div><div>less about side channel hacks inside his home behind a firewall.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So....  I've been thinking, and that's one of my thoughts.</blockquote><div><br></div><div>You might be on the right path.   VLIW can have deep pipelines<br>and pipelining + optimization poked at with hand coded ASM seems</div><div>to be the method at hand for some of these attacks.<br><br>Of interest some old SGI hardware had branch delay slot bug that</div><div>required the kernel to inspect the binary and preload paged.  Should the<br>branch delay code trigger a fault things got messy so the kernel checked</div><div>and made sure there was no fault generated.     Binary objects <br>were also edited by the system to not have a fault at a page boundary<br>by the runtime link loader and editor.   </div><div>This is public now see the MIPS R4400 errata...<br><a href="ftp://ftp.sgi.com/sgi/doc/R4400/R4400_buglist/r4400_2.0_3.0_MC_errata.ps">ftp://ftp.sgi.com/sgi/doc/R4400/R4400_buglist/r4400_2.0_3.0_MC_errata.ps</a><br></div></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">  T o m    M i t c h e l l</div></div>
</div></div>