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:09:00 GMT 2018
On Mon, Jan 8, 2018 at 12:22 PM, H.J. Lu <firstname.lastname@example.org> wrote:
> On Mon, Jan 8, 2018 at 12:17 PM, Sriraman Tallam via binutils
> <email@example.com> wrote:
>> On Mon, Jan 8, 2018 at 11:01 AM, Florian Weimer <firstname.lastname@example.org> 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.
>> * 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.
>> * 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.
>> * 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.
More information about the Binutils