Spectre mitigation

[Carter Schonwald]

Indeed. It’s  worth noting that the discussed cases where you can recover
the perf benefits of branch / jump prediction only work in the context of a
first order and or whole program compilation approach. The ghc rts and
design is not compatible with those approaches today.

I suspect you could get them to work in a whole program optimizing compiler
like MLTON, or a hypothetical compiler for Haskell that has a different rts
rep

On Thu, Jan 4, 2018 at 4:25 PM Elliot Cameron <eacameron at gmail.com> wrote:

> 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 <
> carter.schonwald at gmail.com> 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 <tjakway at nyu.edu> wrote:
>>
>>> 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
>>>>
>>>>
>> _______________________________________________
>> 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/d30f5d96/attachment.html>