tjakway at nyu.edu
Thu Jan 4 16:51:33 UTC 2018
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
On Jan 4, 2018 6:36 AM, "Carter Schonwald" <carter.schonwald at gmail.com>
> 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
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs