Gold Linker Patch: Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715 and in some places called "spectre".

Sriraman Tallam via binutils
Mon Jan 8 18:04:00 GMT 2018

Hello HJ,

On Sun, Jan 7, 2018 at 10:10 AM, H.J. Lu <> wrote:
> On Fri, Jan 5, 2018 at 6:53 PM, Alan Modra <> wrote:
>> On Fri, Jan 05, 2018 at 03:28:34PM -0800, Cary Coutant wrote:
>>> > It's also incompatible with shadow stack support, so the binary marker for
>>> > that needs to be removed.
>>> Ugh. But that marker shouldn't be set in the first place, since this
>>> linker option is useful only in conjunction with a corresponding
>>> compiler option.
>>> > I don't think this is the right approach at all.  What is this trying to
>>> > accomplish?  What kind of speculation barrier does this implement on current
>>> > CPUs?  Isn't this *extremely* costly?
>>> Supposedly, this strategy aims to disable branch prediction for all
>>> indirect branches in a piece of code, so that attackers cannot use
>>> branch predictor training to force the speculative execution of any
>>> available "gadgets" in the target code. I haven't yet seen any claims
>>> where branch predictor training by itself can be exploited -- it's
>>> simply one way to exploit the cache side channel vulnerabilities.
>> I don't think it's just the victim code.  It seems to me that you'd
>> need to disable indirect branch prediction for all indirect branches
>> in the victim address space.  So it won't be sufficient to simply
>> relink the app with fancy PLT call code.  You'd need to relink *all*
>> libraries that make PLT calls, including, too.  (libc PLT
>> calls to __tls_get_addr, calloc and any ifunc come to mind as possible
>> attack vectors.)  And of course recompile everything to mitigate any
>> inline function pointer calls.
>> Unless I'm missing something, this makes the fancy PLT mitigation
>> unworkable in practice.  You will definitely not want a slow shared
>> libc, libstdc++ etc. to be used by all applications.  So build a set
>> of hardened static libraries and link them into your hardened app.
>> No PLT calls involved, and thus no PLT mitigation needed.
> Adding x86-64 psABI group.
> Also Florian pointed out, this doesn't work for shadow stack.  If you
> are really concerned about PLT, you should avoid PLT altogether as
> suggested by
> This feature has been implemented in GCC + binutils.

Are you referring to the no-plt feature?   If that is the case, I
contributed to  the -fno-plt option in GCC and also in LLVM and the
gold patches to binutils,  and I did bring this up.  The problem is
there is still an indirect jmp directly from the callsite via the GOT
and hence it is still exposed to the attack.


> --
> H.J.

More information about the Binutils mailing list