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

Alan Modra
Sat Jan 6 02:53:00 GMT 2018

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.

Alan Modra
Australia Development Lab, IBM

More information about the Binutils mailing list