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 6:44 PM, Sriraman Tallam <tmsriram@google.com> wrote:

> On Mon, Jan 8, 2018 at 10:40 AM, Florian Weimer <fweimer@redhat.com>
> wrote:
> > On 01/08/2018 07:35 PM, Sriraman Tallam wrote:
> >>
> >> On Mon, Jan 8, 2018 at 10:23 AM, Florian Weimer <fweimer@redhat.com>
> >> wrote:
> >>>
> >>> On 01/08/2018 07:19 PM, Sriraman Tallam wrote:
> >>>>
> >>>>
> >>>> * Regarding what HJ said, unless I misunderstood, I believe he is
> >>>> referring to using fno-plt.  We considered that but the problem is the
> >>>> indirect jump still exists, but now at the call site.  The mitigation
> >>>> would still be necessary at the call site as it is still exposed to
> >>>> the attack.
> >>>
> >>>
> >>>
> >>> But you'll have to patch GCC anyway to change the opcode sequence for
> >>> indirect jumps (just think of vtable dispatch), and then -fno-plt most
> >>> likely would move the dynamic linker and PLT stubs completely out of
> the
> >>> equation.
> >>
> >>
> >> * Yes, you are right and we did work to patch LLVM with this,
> >> https://reviews.llvm.org/D41723
> >> * If we use fno-plt, we could just do the work of patching the call
> >> site in the compiler and completely avoid the linker.  We did note
> >> that, but the downside is losing out on lazy binding which could
> >> affect mobile applications where  I believe this is pretty crucial,
> >
> >
> > I don't know what “mobile applications“ are, but most distributions make
> > BIND_NOW mandatory, even though it does affect shell script performance.
> > There is hardly anything else which stresses process creation more than
> > shell scripting.
> >
> > Doesn't Android fork off new applications from a zygote process? Then the
> > binding overhead would be incurred only once, and BIND_NOW would even
> reduce
> > footprint slightly (because the GOT is no longer dirtied in the child
> > processes).
>
> Not sure, but I was referring to Chrome OS.  I assumed they were using
> lazy binding for start-up time but I checked with Rahul right now who
> confirms that is not the case so this is my wrong assumption.
>

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.

Thanks'
> Sri
>
> >
> > Thanks,
> > Florian
>