<div dir="ltr"><div><div>> 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. <br><br></div>As far as I understand, that's not really true. If you have a process, which has secrets that you do not want to leak to arbitrary other code running on the same CPU, then not only do you need to avoid indirect branches in your side-channel resistent part (as is the case today) but the *rest* of the program also should not contain indirect branches (assuming the presence of gadgets which make memory leaking possible). So even if your crypto library uses no indirect branches and is side-channel resistant, that is no longer enough: if you link it into a program where other parts of the program have indirect branches, then you can use those branches to potentially leak the crypto keys.<br><br></div>So in general, you need to apply mitigations for this attack if you, at any time, store secrets in the process memory that you do not want to be leaked (and being a hardware bug, leaking means that they can, potentially, be leaked to arbitrary users. Privilege-separation provided by the OS does not really matter here, so in theory it may be possible to leak it from JavaScript running in a browser sandbox for example.).<br></div><br><div class="gmail_quote"><div dir="ltr">Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> schrieb am Fr., 5. Jan. 2018 um 00:07 Uhr:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">Indeed. It’s worth noting that the discussed cases where you can recover the perf benefits of branch / jump prediction only work in the context of a first order and or whole program compilation approach. The ghc rts and design is not compatible with those approaches today. </div><div dir="auto"><br></div><div dir="auto">I suspect you could get them to work in a whole program optimizing compiler like MLTON, or a hypothetical compiler for Haskell that has a different rts rep </div></div><div><br><div class="gmail_quote"><div>On Thu, Jan 4, 2018 at 4:25 PM Elliot Cameron <<a href="mailto:eacameron@gmail.com" target="_blank">eacameron@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 class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">This may be relevant: <a href="https://support.google.com/faqs/answer/7625886" target="_blank">https://support.google.com/faqs/answer/7625886</a></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Note that both GCC and LLVM will be learning this Ratpoline technique.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 4, 2018 at 1:55 PM, Carter Schonwald <span><<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">With the caveat of that I maybe have no clue what I’m talking about ;) : </div><div dir="auto"><br></div><div dir="auto">It’s a pretty epic attack/ side channel, but it still requires code execution. </div><div dir="auto"><br></div><div dir="auto">The kernel side channel more of an issue for vm providers </div><div dir="auto"><br></div><div dir="auto">And the spectre one probably will most heavily impact security conscious organizations that might be considering using tools like moby/ docker / Linux containers / kubernetes / mesos/ etc which depend on OS level process isolation etc for security. </div><div dir="auto"><br></div><div dir="auto">My fuzzy understanding is that one fix would be hardware support for per process isolation of memory even in the context users / processes ... which isn’t in any kit afaik. </div><div dir="auto"><br></div><div dir="auto">I do like my code not being slow. So it’s a dilemma :/</div><div><div class="m_-5730443950704951165m_8777532751377700621h5"><br><div class="gmail_quote"><div>On Thu, Jan 4, 2018 at 11:51 AM Thomas Jakway <<a href="mailto:tjakway@nyu.edu" target="_blank">tjakway@nyu.edu</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">I'm gonna start reading through the spectre paper in a few minutes but... is this really the death knell for speculative execution on x86/64...? If so, GHC getting patched is going to be pretty low on everyone's list of priorities.</div><div class="gmail_extra"><br><div class="gmail_quote">On Jan 4, 2018 6:36 AM, "Carter Schonwald" <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br type="attribution"><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" target="_blank">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>
<br>_______________________________________________<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>
<br></blockquote></div></div>
</blockquote></div></div></div></div>
<br>_______________________________________________<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>
<br></blockquote></div><br></div>
</blockquote></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>