Spectre mitigation

[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 <demiobenour at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20180104/1dd73a9a/attachment.html>