Is LFENCE really useless against Specter # 2?

Question

Does anyone know why it is recommended to use the LFENCE statement to stop speculative execution in the case of Specter # 1 (checking for crawl / view restrictions without restriction), but is useless in the case of Specter # 2 (injection of the target branch)? Both of these Specter vulnerabilities are associated with speculative execution and use a branch predictor. As I understand it, in the first case a common predictor is involved, and in the second - a pointer to an indirect call. Would it be useful if I start using LFENCE to prevent speculative execution based on indirect call prediction to mitigate Specter # 2?

Answer 1

Of ghost paper

7 Mitigation Options

The vulnerability of a conditional branch can be mitigated if speculative execution can be suspended on potentially dependent execution paths.

This means 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 serialization instruction right in front of the critical security code:

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

to avoid speculating on checking for potential information leakage.

In Specter # 2, an attacker controls an “entry point,” where the CPU assumes that execution will continue. Assuming

lfence
critical code

doesn’t help, because the attacker doesn’t need to call a prediction to target on lfence, they can directly set it to critical code.