Spectre mitigation

[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" <carter.schonwald at 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 <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
>>
>
> _______________________________________________
> 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/66ff8ce2/attachment-0001.html>