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]

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