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
Mon Jan 8 21:24:00 GMT 2018

On Mon, Jan 8, 2018 at 1:14 PM, H.J. Lu <> wrote:
> On Mon, Jan 8, 2018 at 1:09 PM, Sriraman Tallam <> wrote:
>> On Mon, Jan 8, 2018 at 12:22 PM, H.J. Lu <> wrote:
>>> On Mon, Jan 8, 2018 at 12:17 PM, Sriraman Tallam via binutils
>>> <> wrote:
>>>> On Mon, Jan 8, 2018 at 11:01 AM, Florian Weimer <> 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?
>> If a lazy bound symbol cannot be resolved and is not resolved at
>> run-time, now binding will expose the issue.
> Is this the missing definition issue?  I won't call it as "correctness".  I
> consider it as "abuse".  It can even be a security issue when a program
> crashes unexpectedly due to the missing definition.

Agreed and I understood this was Florian's point about good and bad
based on perspective.

>>>>       * 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?
>> I have conducted some experiments with fno-plt for binaries that
>> mostly statically linked with some hot calls to libc.  fno-plt did
>> gives us 0.5 %- 1% improvements here and we have plans to turn this on
>> for performance sensitive binaries.  fno-plt seems to help in reducing
>>  iTLB misses when used in conjunction with kernel huge pages.
> So removing PLT isn't that bad for performance.

Yes, based on what I have seen so far.

>>>>       * 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?
>> Yes,  I can take a look at fixing LLVM fo this.
> I think you should experiment all options before changing PLT.
> --
> H.J.

More information about the Binutils mailing list