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

["Rui Ueyama via binutils" <binutils at sourceware dot org>]

On Mon, Jan 8, 2018 at 9:09 PM, Sriraman Tallam <tmsriram@google.com> wrote:

> On Mon, Jan 8, 2018 at 12:22 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> > 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?
>
> If a lazy bound symbol cannot be resolved and is not resolved at
> run-time, now binding will expose the issue.


A little off-topic, but we can make a change to the dynamic loader so that
it binds an unresolvable PLT entry to a function that prints out an error
message as if it failed to resolve the dynamic symbol lazily and then exit.
That should make the behavior of LD_BIND_NOW exactly the same as with lazy
binding.


> >
> >>       * 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.
> >>
> >>>
> >>> Thanks,
> >>> Florian
> >
> >
> >
> > --
> > H.J.
>