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

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Mon, Jan 8, 2018 at 12:17 PM, Sriraman Tallam via binutils
<binutils@sourceware.org> wrote:
> 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.

What correctness issue?

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

Have you measured performance impact of -fno-plt?

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

Shouldn't LLVM be fixed?

>       * 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



-- 
H.J.