Lines Matching refs:lfence

827 ###### Protect large, load-heavy blocks with a single lfence
829 It may be worth using a single `lfence` instruction at the start of a block
833 would need to exceed that of an `lfence` when *correctly* speculatively
834 executed. But in that case, the `lfence` cost is a complete loss of speculative
836 of using `lfence` indicates few if any hot code patterns where this trade off
938 ##### Use `lfence` to guard function transitions
940 An `lfence` instruction can be used to prevent subsequent loads from
953 sequences exhibit dramatic performance loss when mitigated with `lfence`. This
969 `%rsp` and potentially `lfence` within the function entry block.
987 vulnerable. For x86 systems this is done by either injecting an `lfence`
990 region. On Intel systems, `lfence` [will prevent the speculative load of secret
992 On AMD systems `lfence` is currently a no-op, but can be made
1006 ### Automatic `lfence` on Conditional Edges
1009 inject an `lfence` instruction into both the target and fallthrough
1020 `lfence` instructions into conditional edges at risk of attack. However,
1033 approaches such as the `lfence` instruction. Just as users can restrict the
1034 scope of `lfence` to control its performance impact, this mitigation technique
1044 data both with an `lfence`-based mitigation and load hardening as presented
1046 mitigating with `lfence`, and the overhead of load hardening compared to a
1050 | Benchmark                              | `lfence` | Load Hardening | Mitigated Speedup |
1057 a log-scale speedup ratio of load hardening relative to `lfence` (up -> faster