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

Roger Pau Monné via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 4 10:28:58 PST 2018


On Thu, Jan 04, 2018 at 06:07:51PM +0000, Chandler Carruth wrote:
> On Thu, Jan 4, 2018 at 12:55 PM Roger via Phabricator <
> reviews at reviews.llvm.org> wrote:
> 
> > royger added a comment.
> >
> > AFAICT this change doesn't allow to use different indirect thunks, gcc
> > allows such usage with the
> > -mindirect-branch=thunk-extern/-mindirect-branch-register options. The
> > following patches for example allow Xen to choose the optimal thunk
> > depending on the processor:
> >
> > https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00112.html
> > https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00118.html
> 
> 
> While allowing external thunks seems useful for experimentation, I much
> prefer that we don't have to establish a precise API / ABI for the exact
> thunks. One advantage of the way we're handling this in LLVM is that the
> thunks are *completely* transparent and work cleanly even in dynamic
> executables.
> 
> Is there any benchmark data showing that the different thunk is superior on
> AMD processors? Any official AMD documentation we can cite here?
> 
> We can easily extend this code to generate custom thunks for specific
> processors -- we have that kind of information inside the compiler.

In any case we need the ability to switch the thunks at runtime, it's
not feasible to compile a different kernel for each CPU model. Hence
AFAICT the easiest way to achieve that is to allow external thunks.

Roger.


More information about the llvm-commits mailing list