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.schonw...@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 <demioben...@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@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs