[x86][seses] Don't LFENCE data invariant insts

[zbrid]

Summary

Add a flag to the x86 Speculative Execution Side Effect Suppression Pass
that allows users to turn off LFENCEing data invariant instructions.

Note that the list currently used by this flag does not include
information about vector instructions. That information can be added in
the future with no issues. The fact those instructions have not been
added to this list mean that it's also likely that the improvements
shown in the following performance data is understated.

This is a part of a set of flags that can be used to experiment with
optimizing this mitigation for Load Value Injection.

One pager on Load Value Injection:
https://software.intel.com/security-software-guidance/software-guidance/load-value-injection

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

Performance Testing Results

I ran the BoringSSL benchmarks which run many cryptographic operations
and reports the number of operations per second completed in a given
time.

Modified Mitigation vs Baseline
Geometric mean
0.129 (This can be read as the geomean ops/s of the mitigated program
was 12.9% of the ops/s of the unmitigated program. Similar below.)
Minimum
0.058
Quartile 1
0.104
Median
0.112
Quartile 3
0.139
Maximum
0.459

Fully Mitigated vs Baseline
Geometric mean
0.071
Minimum
0.041
Quartile 1
0.060
Median
0.063
Quartile 3
0.077
Maximum
0.230

[zbrid]

I'll note that this patch doesn't have a test because I couldn't figure out how to write some LLVM IR that lowered to MIR that included a function in the list of data invariant functions in X86InstrInfo. Any tips there would be appreciated!

[craig.topper]

llvm/lib/Target/X86/X86SpeculativeExecutionSideEffectSuppression.cpp

129

Don't the instructions that match isDataInvariantLoad still pull things into the cache?

[zbrid]

llvm/lib/Target/X86/X86SpeculativeExecutionSideEffectSuppression.cpp

129

This may be true. I don't know. Data invariant instructions were supposed to be a stand in for a more specific "instructions that don't release info to side channels" and perhaps that's a very different thing. I think someone with better expertise than I have would need to evaluate whether this is a secure flag to set.

[craig.topper]

llvm/lib/Target/X86/X86SpeculativeExecutionSideEffectSuppression.cpp

129

I think this was only meant to capture instructions whose execution latency doesn't vary based on the data value. For example divide by a power of 2 takes a different number of cycles than division by other values.

llvm/lib/Target/X86/X86SpeculativeExecutionSideEffectSuppression.cpp

OmitLFENCEInBasicBlocksWithoutLoads("x86-seses-omit-lfence-in-bb-without-loads",
                       cl::desc("Omit LFENCE in basic blocks without any loads even if there are stores."),
                       cl::init(false), cl::Hidden);
 
 static cl::opt<bool>
     OmitLFENCEInBasicBlocksWithOneLoadAndNoStores("x86-seses-omit-lfence-in-bb-with-one-load-no-stores",
                       cl::desc("Don't LFENCE in basic blocks with one load and no stores."),
                       cl::init(false), cl::Hidden);
 
+static cl::opt<bool> LFENCEDataInvariantInstructions(
+    "x86-seses-lfence-data-invariant-inst",
+    cl::desc("LFENCE before instructions that are data invariant."),
+    cl::init(true), cl::Hidden);
+
 static bool hasConstantAddressingMode(const MachineInstr &MI);
 
 namespace {
 
 class X86SpeculativeExecutionSideEffectSuppressionPass
     : public MachineFunctionPass {
 public:
   X86SpeculativeExecutionSideEffectSuppressionPass() : MachineFunctionPass(ID) {}
if (OmitLFENCEInBasicBlocksWithoutLoads || OmitLFENCEInBasicBlocksWithOneLoadAndNoStores) {
       if (OmitLFENCEInBasicBlocksWithOneLoadAndNoStores && StoreCount == 0 && LoadCount <= 1) {
         continue;
       }
     }
 
     MachineInstr *FirstTerminator = nullptr;
 
     for (auto &MI : MBB) {
+      // If the current instruction is data invariant and we are not LFENCEing
+      // data invariant instructions, then continue to the next instruction.
+      if (!LFENCEDataInvariantInstructions &&
+          (TII->isDataInvariant(MI) || TII->isDataInvariantLoad(MI))) {
+        continue;
+      }
+
       // We want to put an LFENCE before any instruction that
       // may load or store. This LFENCE is intended to avoid leaking any secret
       // data due to a given load or store. This results in closing the cache
       // and memory timing side channels. We will treat terminators that load
       // or store separately.
       if (MI.mayLoadOrStore() && !MI.isTerminator()) {
         BuildMI(MBB, MI, DebugLoc(), TII->get(X86::LFENCE));
         NumLFENCEsInserted++;