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
> 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
> 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
>> 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>
>>>> 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
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs