Re: 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 at redhat dot com>]

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