<div><a href="https://spectreattack.com/spectre.pdf">https://spectreattack.com/spectre.pdf</a></div><div dir="auto"><br></div><div dir="auto">Has a full exposition for the curious. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">It does seem that compiler level mitigations are one of several proposed approaches , but the performance cost would be great!!!</div><div dir="auto"><br></div><div dir="auto">That said, adding a “hardened” mode flag would be a viable approach if someone wanted to explore that.  Would be a lot of work I think.  Plus I suspect ghcs current architecture wouldn’t be the best starting point rts and compilation model wise ??</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div>On Thu, Jan 4, 2018 at 9:36 AM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">The only impacted code is the code which should already be engineered to be  side channel resistant... which already need to be written in a way that has constant control flow and memory lookup.  </div><div dir="auto"><br></div><div dir="auto">This is just a new and very powerful side channel attack.  It would be interesting and possibly useful to explore fascilities that enable marked pieces of code to be compiled in ways that improve side channel resistance.  But there’s so many different approaches that it’d be difficult to protect against all of them at once for general programs.  </div><div dir="auto"><br></div><div dir="auto">I could be totally wrong, and I should read the spectre paper :)</div><div dir="auto"><br></div><div dir="auto">I guess I just mean that vulnerable Data should be hardened, but only when the cost makes sense.  Every security issue has some finite cost. The sum of those security events cost must be weighed against the sum of the costs of preventing them </div><div><br><div class="gmail_quote"><div>On Thu, Jan 4, 2018 at 9:08 AM Demi Obenour <<a href="mailto:demiobenour@gmail.com">demiobenour@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">The recent “Spectre” bug requires that speculative execution of indirect branches be disabled.  For GHC, this will require passing a flag to LLVM and fixing the NCG to emit suitable calling sequences.<div dir="auto"><br></div><div dir="auto">This will be a disaster for the STG execution model, because it disables CPU branch prediction for indirect calls and jumps.  This is a big argument in favor of doing a CPS→SSA conversion in the backend.</div></div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div></div></blockquote></div></div>