[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..

[Chandler Carruth via Phabricator via llvm-commits]

chandlerc added a comment.

In https://reviews.llvm.org/D41723#967545, @jyknight wrote:

> Looks like this uses a different command-line argument than the preliminary patchset for GCC, which is rather unfortunate.
>  http://git.infradead.org/users/dwmw2/gcc-retpoline.git/shortlog/refs/heads/gcc-7_2_0-retpoline-20171219
>  It'd be awesome if both compilers would somehow end up using the same command-line spelling. Maybe GCC would like to switch to "-mretpoline"? Have we been talking to them?


We have talked to them, but I don't know what the rationale is behind their flag names and there isn't an actual discussion about them that we can comment on. I *strongly* prefer having a single simple flag such as `-mretpoline`.

> However, I do suspect the upstream kernel folks will need the equivalent of "-mindirect-branch=thunk-extern" mode (where the compiler doesn't actually emit the thunks, only the calls to them). This lets them define their own thunks which have "alternatives" annotations in them to allow them to be runtime patched out. (e.g. as in https://lkml.org/lkml/2018/1/4/419).

If the upstream kernel folks want it, and can spell out how it should work, no problem. We've worked on this set of functionality in close coordination with Paul Turner, and this wasn't at the top of the queue of things for us to do, but we can add it whenever/however it is needed. That said....

> That should be easy to support -- just don't do the thunk-emission -- but it does then mean the need to standardize on the names and semantics of the required thunks.

I don't think this is true. We need to document LLVM's semantics and the thunks required. If they match GCCs, cool. If not and a user provides a flag to request an external thunk, then they have to give LLVM one that matches LLVM's semantics. Since they control the name, they can even have thunks with each compiler's semantics and different names. While in practice, I expect the semantics to match, I don't think we should be in the business of forcing this into the ABI. We already have waaaay to much in the ABI. If we come up with a better way to do retpoline in the future, we should rapidly switch to that without needing to coordinate about names and semantics across compilers.

> And it would be good if the same function-names were used as GCC. Fine to do as a followup patch, but maybe at least have an idea what the command-line UI will be for it.

I strongly disagree here. Again, this should *not* be part of the ABI and it should not be something that we have to engineer to match exactly with other compilers. We should even be free to add `__llvm_retpoline2_foo()` thunks in the future with new semantics with zero compatibility concerns.


https://reviews.llvm.org/D41723