Spectre mitigation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Spectre mitigation

Demi Obenour
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Spectre mitigation

Carter Schonwald
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Spectre mitigation

Carter Schonwald

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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Spectre mitigation

Thomas Jakway
In reply to this post by Carter Schonwald
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" <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Spectre mitigation

Carter Schonwald
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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Spectre mitigation

Elliot Cameron-2

Note that both GCC and LLVM will be learning this Ratpoline technique.

On Thu, Jan 4, 2018 at 1:55 PM, Carter Schonwald <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:

Note that both GCC and LLVM will be learning this Ratpoline technique.

On Thu, Jan 4, 2018 at 1:55 PM, Carter Schonwald <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Spectre mitigation

Benno Fünfstück
> 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. 

As far as I understand, that's not really true. If you have a process, which has secrets that you do not want to leak to arbitrary other code running on the same CPU, then not only do you need to avoid indirect branches in your side-channel resistent part (as is the case today) but the *rest* of the program also should not contain indirect branches (assuming the presence of gadgets which make memory leaking possible). So even if your crypto library uses no indirect branches and is side-channel resistant, that is no longer enough: if you link it into a program where other parts of the program have indirect branches, then you can use those branches to potentially leak the crypto keys.

So in general, you need to apply mitigations for this attack if you, at any time, store secrets in the process memory that you do not want to be leaked (and being a hardware bug, leaking means that they can, potentially, be leaked to arbitrary users. Privilege-separation provided by the OS does not really matter here, so in theory it may be possible to leak it from JavaScript running in a browser sandbox for example.).

Carter Schonwald <[hidden email]> schrieb am Fr., 5. Jan. 2018 um 00:07 Uhr:
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 <[hidden email]> wrote:

Note that both GCC and LLVM will be learning this Ratpoline technique.

On Thu, Jan 4, 2018 at 1:55 PM, Carter Schonwald <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Spectre mitigation

Carter Schonwald
Perhaps you are correct.  

That said: the retpoline style mitigation can only recover performance of normal pipelining / branch prediction if you statically know the common jump targets. Which brings you quickly into doing whole compilation strategies like type directed defunctionalization.   

Either way 

1) the attacks require remote code execution. 

2) the Data exfiltration risk only matters if there’s both remote code execution and a communication channel to exfiltrate with.  

 On consumer facing desktop / laptops, the best immediate mitigation is to make sure you’re using Firefox 57.04  (already out )and or chrome >= 64 (due out later this month ).  JavaScript in browsers being a remote code execution environment by design!  There is a very simple mitigation in the case of java script, eg firefox is reducing the resolution of its high precision js timer to 20 microseconds.  Which is afaict a tad too course for the applicable timing side channels 

On server end of things:
Don’t allow unauthorized code executions / remote code executions ! The usual don’t allow code injections or buggy c parsers or return oriented buffer code injection hijinks still apply 

Security is about depth.  This new class of attacks just means that remote code execution where the attacker knows how to interpret the memory layout of the target process is a game over.  

I guess this attack does increase the value proposition of systems configuration tools that whitelist the collection of processes a system is expected to run.  

Will we see attacks that masquerade as systems benchmarking/ microbrnchmarking tools? 

Point being: yes it’s a new very powerful attack.  But that does not mean separate compilation and good performance for higher Order programming languages is now disallowed.  It just means there’s more science and engineering to be done! 


On Fri, Jan 5, 2018 at 4:49 PM Benno Fünfstück <[hidden email]> 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. 

As far as I understand, that's not really true. If you have a process, which has secrets that you do not want to leak to arbitrary other code running on the same CPU, then not only do you need to avoid indirect branches in your side-channel resistent part (as is the case today) but the *rest* of the program also should not contain indirect branches (assuming the presence of gadgets which make memory leaking possible). So even if your crypto library uses no indirect branches and is side-channel resistant, that is no longer enough: if you link it into a program where other parts of the program have indirect branches, then you can use those branches to potentially leak the crypto keys.

So in general, you need to apply mitigations for this attack if you, at any time, store secrets in the process memory that you do not want to be leaked (and being a hardware bug, leaking means that they can, potentially, be leaked to arbitrary users. Privilege-separation provided by the OS does not really matter here, so in theory it may be possible to leak it from JavaScript running in a browser sandbox for example.).

Carter Schonwald <[hidden email]> schrieb am Fr., 5. Jan. 2018 um 00:07 Uhr:
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 <[hidden email]> wrote:

Note that both GCC and LLVM will be learning this Ratpoline technique.

On Thu, Jan 4, 2018 at 1:55 PM, Carter Schonwald <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Spectre mitigation

Demi Obenour
I think a Haskellton (whole program optimizing Haskell compiler) is a VERY good idea.  If we could compile GHC with it and the resulting compiler supported Template Haskell, this could help reduce compile times of normal GHC.

That said, I don't think it is as bad as I thought.  The reason is that the OS kernel and hypervisor can stop this, by invalidating branch prediction information at context switches.  This prevents one process from altering branches in another.

On Jan 6, 2018 10:19 AM, "Carter Schonwald" <[hidden email]> wrote:
Perhaps you are correct.  

That said: the retpoline style mitigation can only recover performance of normal pipelining / branch prediction if you statically know the common jump targets. Which brings you quickly into doing whole compilation strategies like type directed defunctionalization.   

Either way 

1) the attacks require remote code execution. 

2) the Data exfiltration risk only matters if there’s both remote code execution and a communication channel to exfiltrate with.  

 On consumer facing desktop / laptops, the best immediate mitigation is to make sure you’re using Firefox 57.04  (already out )and or chrome >= 64 (due out later this month ).  JavaScript in browsers being a remote code execution environment by design!  There is a very simple mitigation in the case of java script, eg firefox is reducing the resolution of its high precision js timer to 20 microseconds.  Which is afaict a tad too course for the applicable timing side channels 

On server end of things:
Don’t allow unauthorized code executions / remote code executions ! The usual don’t allow code injections or buggy c parsers or return oriented buffer code injection hijinks still apply 

Security is about depth.  This new class of attacks just means that remote code execution where the attacker knows how to interpret the memory layout of the target process is a game over.  

I guess this attack does increase the value proposition of systems configuration tools that whitelist the collection of processes a system is expected to run.  

Will we see attacks that masquerade as systems benchmarking/ microbrnchmarking tools? 

Point being: yes it’s a new very powerful attack.  But that does not mean separate compilation and good performance for higher Order programming languages is now disallowed.  It just means there’s more science and engineering to be done! 


On Fri, Jan 5, 2018 at 4:49 PM Benno Fünfstück <[hidden email]> 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. 

As far as I understand, that's not really true. If you have a process, which has secrets that you do not want to leak to arbitrary other code running on the same CPU, then not only do you need to avoid indirect branches in your side-channel resistent part (as is the case today) but the *rest* of the program also should not contain indirect branches (assuming the presence of gadgets which make memory leaking possible). So even if your crypto library uses no indirect branches and is side-channel resistant, that is no longer enough: if you link it into a program where other parts of the program have indirect branches, then you can use those branches to potentially leak the crypto keys.

So in general, you need to apply mitigations for this attack if you, at any time, store secrets in the process memory that you do not want to be leaked (and being a hardware bug, leaking means that they can, potentially, be leaked to arbitrary users. Privilege-separation provided by the OS does not really matter here, so in theory it may be possible to leak it from JavaScript running in a browser sandbox for example.).

Carter Schonwald <[hidden email]> schrieb am Fr., 5. Jan. 2018 um 00:07 Uhr:
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 <[hidden email]> wrote:

Note that both GCC and LLVM will be learning this Ratpoline technique.

On Thu, Jan 4, 2018 at 1:55 PM, Carter Schonwald <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs