[PATCH] D50837: [x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document.

Chandler Carruth via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 28 22:33:48 PDT 2018


chandlerc added inline comments.


================
Comment at: llvm/lib/Target/X86/X86SpeculativeLoadHardening.cpp:2205-2208
+    // FIXME: It isn't clear that this is reliable in the face of
+    // rematerialization in the register allocator. We somehow need to force
+    // that to not occur for this particular instruction, and instead to spill
+    // or otherwise preserve the value computed *prior* to the call.
----------------
rnk wrote:
> Yeah, that's a real concern... Even if we don't do it today, RA will at one point definitely want to sink this kind of LEA. You could manually do the spill yourself, and maybe mark it volatile. It adds some complexity, but this no redzone / setjmp case should be infrequent and not be performance critical code.
I'd like to do this as a follow-up though, as in practice, it does not seem to happen yet. Is that OK?


================
Comment at: llvm/test/CodeGen/X86/speculative-load-hardening-call-and-ret.ll:105
+; X64-PIC-NEXT:    sarq $63, %rax
+; X64-PIC-NEXT:    leaq {{.*}}(%rip), %rdx
+; X64-PIC-NEXT:    cmpq %rdx, %rcx
----------------
rnk wrote:
> --no_x86_scrub_rip will help make this more obviously correct.
Will regenerate this (and other) test cases with that.

FWIW, happy to have a patch flipping the default.


Repository:
  rL LLVM

https://reviews.llvm.org/D50837





More information about the llvm-commits mailing list