Home Original page

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

H.J. Lu hjl.tools@gmail.com
Sun Jan 7 18:11:00 GMT 2018 
On Fri, Jan 5, 2018 at 6:53 PM, Alan Modra <amodra@gmail.com> 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 libc.so, 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

https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-secure.pdf

This feature has been implemented in GCC + binutils.

-- 
H.J.
More information about the Binutils mailing list