Here's my initial thoughts, bearing in mind that low level stuff is not
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
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.