[PATCH] D41723: Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre..

[David Li via Phabricator via llvm-commits]

davidxl added inline comments.


================
Comment at: clang/lib/Basic/Targets/X86.cpp:1306
       .Case("rdseed", HasRDSEED)
+      .Case("retpoline", HasRetpoline)
       .Case("rtm", HasRTM)
----------------
chandlerc wrote:
> majnemer wrote:
> > Why is this phrased as a target feature? It just seems weird as it is not a hardware capability (all X86 hardware should support the reptoline instruction sequence unless I am mistaken).
> > 
> > Also, it seems that other hardware platforms beyond Intel have problems with speculation of this nature. IMO, this is more similar to things like the relocation-model and the code-model...
> All x86-64 hardware supports SSE and SSE2, but we can still turn them on and off?
> 
> I think it makes some sense as it *only* impacts the target's code generation, not anything produced by Clang etc, and this seems to be a way to pass that down.
> 
> 
> And while other architectures may want to introduce similar mitigations for Spectre, the retpoline construct itself is pretty x86-specific. My suspicion is that other architectures will potentially re-use some of the LLVM infrastructure like removing indirectbr, but want to handle the hard cases with a target-specific technique. So something like relocation-model and code-model seem weird to me as this is (at least so far) a fundamentally x86 thing.
This can go either way.

Fundamentally, the option is used to 'disable' indirect branch predictor  so it sounds like target independent. However the mechanism used here 'retpoline' is very x86 specific -- it forces the HW to use call/ret predictor so that the predicted target is 'trapped' in a loop.


https://reviews.llvm.org/D41723