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

["Sriraman Tallam via binutils" <binutils at sourceware dot org>]

On Mon, Jan 8, 2018 at 11:01 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 01/08/2018 07:51 PM, Rui Ueyama wrote:
>>
>> A drawback of using BIND_NOW is that an application that has a PLT entry
>> that cannot be resolved but not used fails to start with that option.
>
>
> That can be a good or bad thing, depending on your perspective.  With more
> and more use of symbol versioning, the point is increasingly moot because
> the set of symbol versions is not checked lazily.

Ok, my attempt to summarize the discussions around this patch:

a)  We don't need this patch.
      * We could deploy fno-plt and now binding and remove PLTs
altogether. We have to fix correctness issues related to these, like
the one Rui pointed out.
      * One other pain point is we do have internally is we use a
configuration for tests where we build a number of shared objects and
keep the main binary pretty thin.  We have explicitly disabled now
binding for this due to performance reasons, huge increase in the
number of dynamic relocations putting unacceptable overheads on our
distributed build system.  We need to find a solution here.
      * The compiler is eliminating indirect branches and calls
anyway, might as well do it with fno-plt also.  With
-mindirect-branch=think this might also be unnecessary but LLVM
atleast does not support this yet.
      * We still have to find a solution to avoid PLTs for shared
objects, needs re-building and fixing performance issues.
      * We could use static linking but that is not an immediate solution.

b) We have this patch in the linker:
     * If we want to continue to use lazy binding or just keep PLTs as
it is and take the penalty for the project, this is easy.
     * My testing with retpoline for large programs shows this is
pretty straightforward to deploy, I did not run into any correctness
issues that requires large-scale fixing of builds.
     * All other problems from a) exist. Shared libraries still need
to be fixed,  compiler needs to be fixed to avoid indirect calls, etc.

>
> Thanks,
> Florian