[all-commits] [llvm/llvm-project] bf95cf: [x86][seses] Introduce SESES pass for LVI

[zbrid via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: bf95cf4a6816476afd76d5b981ea5fdcb9771999
      https://github.com/llvm/llvm-project/commit/bf95cf4a6816476afd76d5b981ea5fdcb9771999
  Author: Zola Bridges <zbrid at google.com>
  Date:   2020-05-11 (Mon, 11 May 2020)

  Changed paths:
    M llvm/lib/Target/X86/CMakeLists.txt
    M llvm/lib/Target/X86/X86.h
    A llvm/lib/Target/X86/X86SpeculativeExecutionSideEffectSuppression.cpp
    M llvm/lib/Target/X86/X86TargetMachine.cpp
    M llvm/test/CodeGen/X86/O0-pipeline.ll
    M llvm/test/CodeGen/X86/O3-pipeline.ll
    A llvm/test/CodeGen/X86/speculative-execution-side-effect-suppression.ll

  Log Message:
  -----------
  [x86][seses] Introduce SESES pass for LVI

This is an implementation of Speculative Execution Side Effect
Suppression which is intended as a last resort mitigation against Load
Value Injection, LVI, a newly disclosed speculative execution side
channel vulnerability.

One pager:
https://software.intel.com/security-software-guidance/software-guidance/load-value-injection

Deep dive:
https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection

The mitigation consists of a compiler pass that inserts an LFENCE before
each memory read instruction, memory write instruction, and the first
branch instruction in a group of terminators at the end of a basic
block. The goal is to prevent speculative execution, potentially based
on misspeculated conditions and/or containing secret data, from leaking
that data via side channels embedded in such instructions.

This is something of a last-resort mitigation: it is expected to have
extreme performance implications and it may not be a complete mitigation
due to trying to enumerate side channels.

In addition to the full version of the mitigation, this patch
implements three flags to turn off part of the mitigation. These flags
are disabled by default. The flags are not intended to result in a
secure variant of the mitigation. The flags are intended to be used by
users who would like to experiment with improving the performance of
the mitigation. I ran benchmarks with each of these flags enabled in
order to find if there was any room for further optimization of LFENCE
placement with respect to LVI.

Performance Testing Results

When applying this mitigation to BoringSSL, we see the following
results. These are a summary/aggregation of the performance changes when
this mitigation is applied versus when no mitigation is applied.

Fully Mitigated vs Baseline
Geometric mean
0.071 (Note: This can be read as the ops/s of the mitigated
program was 7.1% of the ops/s of the unmitigated program.)
Minimum
0.041
Quartile 1
0.060
Median
0.063
Quartile 3
0.077
Maximum
0.230

Reviewed By: george.burgess.iv

Differential Revision: https://reviews.llvm.org/D75939