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

[Florian Weimer <fweimer at redhat dot com>]

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

Thanks,
Florian