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.
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 On Thu, Jan 4, 2018 at 4:25 PM Elliot Cameron <eacame...@gmail.com> wrote: > This may be relevant: https://support.google.com/faqs/answer/7625886 > > Note that both GCC and LLVM will be learning this Ratpoline technique. > > On Thu, Jan 4, 2018 at 1:55 PM, Carter Schonwald < > carter.schonw...@gmail.com> wrote: > >> With the caveat of that I maybe have no clue what I’m talking about ;) : >> >> It’s a pretty epic attack/ side channel, but it still requires code >> execution. >> >> The kernel side channel more of an issue for vm providers >> >> 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. >> >> 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. >> >> I do like my code not being slow. So it’s a dilemma :/ >> >> On Thu, Jan 4, 2018 at 11:51 AM Thomas Jakway <tjak...@nyu.edu> wrote: >> >>> 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. >>> >>> On Jan 4, 2018 6:36 AM, "Carter Schonwald" <carter.schonw...@gmail.com> >>> wrote: >>> >>>> 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. >>>> >>>> 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. >>>> >>>> I could be totally wrong, and I should read the spectre paper :) >>>> >>>> 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 >>>> >>>> On Thu, Jan 4, 2018 at 9:08 AM Demi Obenour <demioben...@gmail.com> >>>> wrote: >>>> >>>>> 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. >>>>> >>>>> 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. >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs@haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>> >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs@haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
