Skip to content
This repository was archived by the owner on Feb 5, 2019. It is now read-only.

Commit 8e3c7f6

Browse files
committed
[x86/SLH] Clean up helper naming for return instruction handling and
remove dead declaration of a call instruction handling helper. This moves to the 'harden' terminology that I've been trying to settle on for returns. It also adds a really detailed comment explaining what all we're trying to accomplish with return instructions and why. Hopefully this makes it much more clear what exactly is being "hardened". Differential Revision: https://reviews.llvm.org/D49571 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337510 91177308-0d34-0410-b5e6-96231b3b80d8
1 parent fc13800 commit 8e3c7f6

File tree

1 file changed

+26
-4
lines changed

1 file changed

+26
-4
lines changed

lib/Target/X86/X86SpeculativeLoadHardening.cpp

Lines changed: 26 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -192,8 +192,7 @@ class X86SpeculativeLoadHardeningPass : public MachineFunctionPass {
192192
SmallPtrSetImpl<MachineInstr *> &HardenedInstrs);
193193
bool canHardenRegister(unsigned Reg);
194194
void hardenPostLoad(MachineInstr &MI);
195-
void checkReturnInstr(MachineInstr &MI);
196-
void checkCallInstr(MachineInstr &MI);
195+
void hardenReturnInstr(MachineInstr &MI);
197196
};
198197

199198
} // end anonymous namespace
@@ -529,7 +528,7 @@ bool X86SpeculativeLoadHardeningPass::runOnMachineFunction(
529528
if (!MI.isReturn())
530529
continue;
531530

532-
checkReturnInstr(MI);
531+
hardenReturnInstr(MI);
533532
}
534533

535534
LLVM_DEBUG(dbgs() << "Final speculative load hardened function:\n"; MF.dump();
@@ -1969,7 +1968,30 @@ void X86SpeculativeLoadHardeningPass::hardenPostLoad(MachineInstr &MI) {
19691968
++NumPostLoadRegsHardened;
19701969
}
19711970

1972-
void X86SpeculativeLoadHardeningPass::checkReturnInstr(MachineInstr &MI) {
1971+
/// Harden a return instruction.
1972+
///
1973+
/// Returns implicitly perform a load which we need to harden. Without hardening
1974+
/// this load, an attacker my speculatively write over the return address to
1975+
/// steer speculation of the return to an attacker controlled address. This is
1976+
/// called Spectre v1.1 or Bounds Check Bypass Store (BCBS) and is described in
1977+
/// this paper:
1978+
/// https://people.csail.mit.edu/vlk/spectre11.pdf
1979+
///
1980+
/// We can harden this by introducing an LFENCE that will delay any load of the
1981+
/// return address until prior instructions have retired (and thus are not being
1982+
/// speculated), or we can harden the address used by the implicit load: the
1983+
/// stack pointer.
1984+
///
1985+
/// If we are not using an LFENCE, hardening the stack pointer has an additional
1986+
/// benefit: it allows us to pass the predicate state accumulated in this
1987+
/// function back to the caller. In the absence of a BCBS attack on the return,
1988+
/// the caller will typically be resumed and speculatively executed due to the
1989+
/// Return Stack Buffer (RSB) prediction which is very accurate and has a high
1990+
/// priority. It is possible that some code from the caller will be executed
1991+
/// speculatively even during a BCBS-attacked return until the steering takes
1992+
/// effect. Whenever this happens, the caller can recover the (poisoned)
1993+
/// predicate state from the stack pointer and continue to harden loads.
1994+
void X86SpeculativeLoadHardeningPass::hardenReturnInstr(MachineInstr &MI) {
19731995
MachineBasicBlock &MBB = *MI.getParent();
19741996
DebugLoc Loc = MI.getDebugLoc();
19751997
auto InsertPt = MI.getIterator();

0 commit comments

Comments
 (0)