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

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Mon, Jan 8, 2018 at 10:22 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Jan 8, 2018 at 10:19 AM, Sriraman Tallam via binutils
> <binutils@sourceware.org> wrote:
>> Hi Cary,
>>
>> On Sun, Jan 7, 2018 at 3:14 PM, Cary Coutant <ccoutant@gmail.com> wrote:
>>>> We aren't patching linkers just because we can. ;]
>>>
>>> Chandler, if I didn't know you personally, I'd take offense. Hmm,
>>> maybe I took a wee bit of offense, even so. :-) Snark isn't going to
>>> get you anywhere; it's more likely to close minds.
>>>
>>> The details of these vulnerabilities are out there now, and your
>>> little circle is much bigger. That means you're now exposed to people
>>> with different experiences and possibly more expertise. Even if you've
>>> already been down certain paths and answered certain questions, you're
>>> going to need to do it again for the rest of us. People on this thread
>>> are asking reasonable questions, and if you want help and cooperation,
>>> those questions deserve serious answers. Together, we may even come up
>>> with better solutions.
>>>
>>> In particular, I'd like to know your answer to Alan's question about
>>> the performance implications of deploying slow shared libraries where
>>> not all applications need this mitigation, and the suggestion to just
>>> compile secure apps statically. I'd like to know your answer to HJ's
>>> suggestion to eliminate the PLT altogether (I have an answer to that,
>>> but I'd like to know yours).
>>
>> Let me try to answer some of these questions since these were
>> discussed and considered:
>>
>> * Plain Static linking is going to be a problem since it does not work
>> with PIE + static.  We have investigated using musl libc to enable
>> static linking + PIE and we had somebody who was successfully able to
>> link the dynamic relocator within a statlic binary to make PIE work
>> but it looks like it is going to be quite a while before this can be
>> deployed.
>> * We are looking at partially statically linking hot memops to remove
>> the PLT + ifunc penalty for these calls.  I understand that we may
>> still have to rebuild libc.so to use retpoline maybe.
>> * 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.
>
> Not with GCC using -mindirect-branch=thunk -fno-plt.
>

[hjl@gnu-bdw-1 indirect-2]$ cat x.i
void func (void);

void
bar (void)
{
  func ();
}
[hjl@gnu-bdw-1 indirect-2]$ make x.o
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -g
-mindirect-branch=thunk -fpie -fno-plt -c x.i
[hjl@gnu-bdw-1 indirect-2]$ objdump -dwr x.o

x.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <bar>:
   0: 48 8b 05 00 00 00 00 mov    0x0(%rip),%rax        # 7 <bar+0x7>
3: R_X86_64_REX_GOTPCRELX func-0x4
   7: e9 00 00 00 00        jmpq   c <bar+0xc> 8: R_X86_64_PC32
__x86.indirect_thunk.rax-0x4

Disassembly of section .text.__x86.indirect_thunk.rax:

0000000000000000 <__x86.indirect_thunk.rax>:
   0: e8 05 00 00 00        callq  a <__x86.indirect_thunk.rax+0xa>
   5: 0f ae e8              lfence
   8: eb fb                jmp    5 <__x86.indirect_thunk.rax+0x5>
   a: 48 89 04 24          mov    %rax,(%rsp)
   e: c3                    retq
[hjl@gnu-bdw-1 indirect-2]$



-- 
H.J.