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

Florian Weimer fweimer@redhat.com
Fri Jan 5 11:42:00 GMT 2018


On 01/05/2018 12:08 AM, Cary Coutant wrote:
>> * options.h (retpolineplt): New -z option to use retpoline PLT.
>> * x86_64.cc (Output_data_plt_x86_64_retpoline): New class.
>> (Target_x86_64<64>::do_make_data_plt): Create retpoline PLT when
>> the option is used.
>> * testsuite/Makefile.am (retpoline_plt_1.sh): New test.
>> * testsuite/Makefile.in: Regenerate.
>> * testsuite/retpoline_plt_1.sh: New test script.
>> * testsuite/retpoline_plt_1.s: New test source.
> 
> This makes the -z bndplt and -z retpolineplt options mutually
> exclusive. Please add a check in options.cc
> (General_options::finalize) for this.

It's also incompatible with shadow stack support, so the binary marker 
for that needs to be removed.

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?

If we think this is a problem that needs to be fixed, we should remove 
the indirect call altogether, and have the dynamic linker generate a 
direct call at load time.  There are few constraints associated with 
that (4 GiB total application + DSO size, some SELinux users will 
unhappy, lack of lazy binding support), but at least it can be turned on 
in practice.

Thanks,
Florian



More information about the Binutils mailing list