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