LFENCE is really useless vs. Spectre #2?

Question

Does anyone know why the LFENCE instruction is recommended to stop speculative execution in case of Spectre #1 (bounds check bypass/out-of-bound read), but is useless in case of Spectre #2 (branch target injection)? Both these Spectre vulnerabilities are related to speculative execution and are exploiting the branch predictor. As I understand in first case the generic predictor is involved and in second the indirect call predictor. Will it useful if I'm starting to use LFENCE to prevent speculative execution based on indirect call predictor to mitigate Spectre #2?

Answer 1

From the Spectre paper

7 Mitigation Options

The conditional branch vulnerability can be mitigated if speculative execution can be halted on potentially- sensitive execution paths.

What this means is that if you have code like

if (security critical check)
  execute critical code
else 
  do not execute critical code

then you need to place the serializing instruction right before the security critical code:

if (security critical check)
  lfence
  execute critical code
else 
  do not execute critical code

to avoid speculation on the check to potentially leak information.

In Spectre #2, the attacker controls the "entry point" where the CPU speculates the execution will continue. Putting

lfence
critical code

does not help, because the attacker doesn't have to cause prediction to target the lfence, they can make it target the critical code directly.