Spectre mitigation

Elliot Cameron eacameron at gmail.com
Thu Jan 4 21:24:41 UTC 2018


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/8500b6f5/attachment-0001.html>


More information about the ghc-devs mailing list