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

["Sriraman Tallam via binutils" <binutils at sourceware dot org>]

+H J Lu

On Thu, Jan 4, 2018 at 9:21 AM, Sriraman Tallam <tmsriram@google.com> wrote:
>
> TLDR; Introduce the "retpoline" mitigation technique for variant #2 of the
> speculative execution vulnerabilities on Intel (and perhaps other) CPUs,
> specifically identified by CVE-2017-5715 and in some places called
> “spectre”. Retpoline PLTs can be enabled by using the linker flag
> “-z,retpolineplt” on x86-64 only.  Patch attached for the gold linker.
>
> This "retpoline" mitigation is fully described in the following blog post:
> https://support.google.com/faqs/answer/7625886
>
>
> Description of retpoline PLT
> -------------------------------------
>
> A standard PLT entry looks like this:
>
>
> 4005d0:  jmpq   *0x1a12(%rip)        # 401fe8 <_GLOBAL_OFFSET_TABLE_+0x18>
> 4005d6:  pushq  $0x0
> 4005db:  jmpq   4005c0 <_init+0x20>
>
>
> It is 16 byte aligned and 16 bytes in size and has three instructions.
>
>
> A retpoline PLT entry looks like this:
>
>
> 4005e0:  mov    0x1a01(%rip),%r11        # 401fe8
> <_GLOBAL_OFFSET_TABLE_+0x18>
> 4005e7:  callq  4005f0 <_Z13ethethopolinev@plt>
> 4005ec:  pause
> 4005ee:  jmp    4005ec <__gmon_start__@plt+0xc>
> 00000000004005f0 <_Z13ethethopolinev@plt>:
> 4005f0:  mov    %r11,(%rsp)
> 4005f4:  retq
> 4005f5:  pushq  $0x0
> 4005fa:  jmpq   4005c0 <_init+0x20>
>
> It is 32 byte aligned and 32 bytes in size. The retpoline PLT entry retains
> the last two instructions from the standard PLT entry to support lazy
> binding.  However, the first indirect jump instruction is replaced by a 6
> instruction code sequence which moves the target address of the jump to
> register r11 and calls a function that returns to the target address by
> manipulating the stack.
>
>
> Future optimizations around this work will include -z,now support for a
> 16-byte entry.
>
>
> What you should know?
> --------------------------------
>
> * Techniques such as PGO and LTO dramatically reduce the impact of hot
> indirect calls (by speculatively promoting them to direct calls). If you
> need to deploy these techniques in C++ applications, we *strongly* recommend
> that you ensure all hot call targets are statically linked (avoiding PLT
> indirection) and use both PGO and LTO. Well tuned servers using all of these
> techniques saw 5% - 10% overhead from the use of the full retpoline
> mitigation (including compiler support).
>
> * Binutils tools like readelf and objdump will not disassemble the PLT
> section accurately as they assume that the PLT entry size is 16 bytes.  A
> patch to fix this is in progress.
>
>
> Testing:
> ---------
>
> Checked that all gold tests pass when retpoline PLT is switched on.  Also
> built and ran a huge search benchmark with retpoline PLT enabled.
>
>
> ChangeLog:
> ----------------
>
> * options.h (retpolineplt): New -z option to use retpoline PLT.
> * x86_64.cc (Output_data_plt_x86_64_retpoline): New class.
> (Target_x86_64<64>::do_make_data_plt): Create retpoline PLT when
> the option is used.
> * testsuite/Makefile.am (retpoline_plt_1.sh): New test.
> * testsuite/Makefile.in: Regenerate.
> * testsuite/retpoline_plt_1.sh: New test script.
> * testsuite/retpoline_plt_1.s: New test source.
>
> Many thanks to Chandler, Reid, Eric, Rui and Brooks!
>
>
> Patch attached.
>
> Thanks
> Sri
>

Attachment: retpoline_plt_patch.txt
Description: Text document