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 binutils@sourceware.org
Mon Jan 8 18:36:00 GMT 2018


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, it
reduces start-up time significantly.  HJ's patch might change this and
I have not taken a look at this yet.
* We did consider these and it did not seem very hard to patch the PLT.

Your thoughts?

Thanks
Sri


>
> A DSO boundary is not a trust boundary, so this is not comparable to the
> kernel situation at all.  For a generic solution, you need to rewrite all
> indirect function calls.
>
> Thanks,
> Florian



More information about the Binutils mailing list