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 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 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" 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 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