[PATCH] D49663: [x86/SLH] Teach the x86 speculative load hardening pass to harden against v1.2 BCBS attacks directly.

[Chandler Carruth via Phabricator via llvm-commits]

chandlerc created this revision.
chandlerc added reviewers: echristo, craig.topper.
Herald added subscribers: hiraditya, mcrosier, sanjoy.

Attacks using spectre v1.2 (a subset of BCBS) are described in the paper
here:
https://people.csail.mit.edu/vlk/spectre11.pdf

The core idea is to speculatively store over the address in a vtable,
jumptable, or other target of indirect control flow that will be
subsequently loaded. Speculative execution after such a store can
forward the stored value to subsequent loads, and if called or jumped
to, the speculative execution will be steered to this potentially
attacker controlled address.

Up until now, this could be mitigated by enableing retpolines. However,
that is a relatively expensive technique to mitigate this particular
flavor. Especially because in most cases SLH will have already mitigated
this. To fully mitigate this with SLH, we need to do two core things:

1. Unfold loads from calls and jumps, allowing the loads to be post-load hardened.
2. Force hardening of incoming registers even if we didn't end up needing to harden the load itself.

The reason we need to do these two things is because hardening calls and
jumps from this particular variant is importantly different from
hardening against leak of secret data. Because the "bad" data here isn't
a secret, but in fact speculatively stored by the attacker, it may be
loaded from any address, regardless of whether it is read-only memory,
mapped memory, or a "hardened" address. The only 100% effective way to
harden these instructions is to harden the their operand itself. But to
the extent possible, we'd like to take advantage of all the other
hardening going on, we just need a fallback in case none of that
happened to cover the particular input to the control transfer
instruction.

This patch implements all of this, but it isn't quite ready to go yet.
First, there is some duplicated code between this patch and the
post-load hardening. I'll work on refactoring that code separately and
then this patch will simplify when rebased. I also need to test to see
what (if anything) we need to do so that these hardening steps are
naturally skipped when retpolines are in fact enabled, but that should
be trivial.

However, this patch shows all of the important mechanics here, including
the hoops we have to go through to unfold the loads from all of the
different instructions and then harden their incoming registers. It also
shows the expected result on the indirect test case.

For users of SLH, currently they are paing 2% to 6% performance overhead
for retpolines, but this mechanism is expected to be substantially
cheaper.


Repository:
  rL LLVM

https://reviews.llvm.org/D49663

Files:
  llvm/lib/Target/X86/X86InstrFoldTables.cpp
  llvm/lib/Target/X86/X86SpeculativeLoadHardening.cpp
  llvm/test/CodeGen/X86/speculative-load-hardening-indirect.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D49663.156751.patch
Type: text/x-patch
Size: 15756 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180723/ced62e05/attachment.bin>