Has anyone thought about the impact of the Spectre attack (https://spectreattack.com/spectre.pdf) on Haskell programs, and mitigations? Here's my initial thoughts, bearing in mind that low level stuff is not my forte.. There are likely to be many gadgets in the ghc RTS that could be used by a Spectre variant 2 attack, using indirect branch poisoning. Since the RTS is mostly C code, C compiler mitigations such as retpoline can avoid the indirect branch prediction problems. There's also assembly in the RTS. For example, StgCRun.c contains a "jmp eax" indirect branch which might be vulnerable. FFI code can also contain vulnerable indirect branches both C and assembly. It would be good if at least securemem wasn't vulnerable to Spectre variant 2, so that Haskell programs operating on very private data could use it to avoid the attack. But, even if securemem itself doesn't contain any vulnerable gadgets (its constant time Eq shouldn't branch, which helps..), other vulnerable gadgets in the RTS and elsewhere can still be pointed at the securemem buffer. I do have Haskell programs that I would like to harden against Spectre variant 2, since they're sometimes used in a multi-user environment and operate on private data. As for Spectre variant 1, it would need something like a haskell implementation of a javascript interpreter running untrusted code, or something like lambdabot running safe haskell code. That would then be vulnerable to conditional branch misprediction to expose whatever private data the process has access to. Perhaps a sufficiently smart compiler could do something about Spectre variant 1, but there are probably not too many vulnetable programs and it can be prevented in the program by eg avoiding exposure of high-resolution timers, the same way web browsers have been dealing with this attack. -- see shy jo