[PATCH] D49571: [x86/SLH] Clean up helper naming for return instruction handling and remove dead declaration of a call instruction handling helper.

Chandler Carruth via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 19 16:51:45 PDT 2018


This revision was automatically updated to reflect the committed changes.
Closed by commit rL337510: [x86/SLH] Clean up helper naming for return instruction handling and (authored by chandlerc, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D49571?vs=156371&id=156391#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D49571

Files:
  llvm/trunk/lib/Target/X86/X86SpeculativeLoadHardening.cpp


Index: llvm/trunk/lib/Target/X86/X86SpeculativeLoadHardening.cpp
===================================================================
--- llvm/trunk/lib/Target/X86/X86SpeculativeLoadHardening.cpp
+++ llvm/trunk/lib/Target/X86/X86SpeculativeLoadHardening.cpp
@@ -192,8 +192,7 @@
                            SmallPtrSetImpl<MachineInstr *> &HardenedInstrs);
   bool canHardenRegister(unsigned Reg);
   void hardenPostLoad(MachineInstr &MI);
-  void checkReturnInstr(MachineInstr &MI);
-  void checkCallInstr(MachineInstr &MI);
+  void hardenReturnInstr(MachineInstr &MI);
 };
 
 } // end anonymous namespace
@@ -529,7 +528,7 @@
       if (!MI.isReturn())
         continue;
 
-      checkReturnInstr(MI);
+      hardenReturnInstr(MI);
     }
 
   LLVM_DEBUG(dbgs() << "Final speculative load hardened function:\n"; MF.dump();
@@ -1969,7 +1968,30 @@
   ++NumPostLoadRegsHardened;
 }
 
-void X86SpeculativeLoadHardeningPass::checkReturnInstr(MachineInstr &MI) {
+/// Harden a return instruction.
+///
+/// Returns implicitly perform a load which we need to harden. Without hardening
+/// this load, an attacker my speculatively write over the return address to
+/// steer speculation of the return to an attacker controlled address. This is
+/// called Spectre v1.1 or Bounds Check Bypass Store (BCBS) and is described in
+/// this paper:
+/// https://people.csail.mit.edu/vlk/spectre11.pdf
+///
+/// We can harden this by introducing an LFENCE that will delay any load of the
+/// return address until prior instructions have retired (and thus are not being
+/// speculated), or we can harden the address used by the implicit load: the
+/// stack pointer.
+///
+/// If we are not using an LFENCE, hardening the stack pointer has an additional
+/// benefit: it allows us to pass the predicate state accumulated in this
+/// function back to the caller. In the absence of a BCBS attack on the return,
+/// the caller will typically be resumed and speculatively executed due to the
+/// Return Stack Buffer (RSB) prediction which is very accurate and has a high
+/// priority. It is possible that some code from the caller will be executed
+/// speculatively even during a BCBS-attacked return until the steering takes
+/// effect. Whenever this happens, the caller can recover the (poisoned)
+/// predicate state from the stack pointer and continue to harden loads.
+void X86SpeculativeLoadHardeningPass::hardenReturnInstr(MachineInstr &MI) {
   MachineBasicBlock &MBB = *MI.getParent();
   DebugLoc Loc = MI.getDebugLoc();
   auto InsertPt = MI.getIterator();


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D49571.156391.patch
Type: text/x-patch
Size: 2555 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180719/78f07a60/attachment.bin>


More information about the llvm-commits mailing list