This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
+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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |