Spectre mitigation

[Carter Schonwald]

https://spectreattack.com/spectre.pdf

Has a full exposition for the curious.


It does seem that compiler level mitigations are one of several proposed
approaches , but the performance cost would be great!!!

That said, adding a “hardened” mode flag would be a viable approach if
someone wanted to explore that.  Would be a lot of work I think.  Plus I
suspect ghcs current architecture wouldn’t be the best starting point rts
and compilation model wise ??

On Thu, Jan 4, 2018 at 9: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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20180104/709614c0/attachment.html>