This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
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".
- From: "Sriraman Tallam via binutils" <binutils at sourceware dot org>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Cary Coutant <ccoutant at gmail dot com>, Chandler Carruth <chandlerc at google dot com>, Florian Weimer <fweimer at redhat dot com>, binutils <binutils at sourceware dot org>, Reid Kleckner <rnk at google dot com>, Eric Christopher <echristo at google dot com>, Rui Ueyama <ruiu at google dot com>, Brooks Moses <bmoses at google dot com>, Sidney Hummert <shummert at google dot com>, Xinliang David Li <davidxl at google dot com>
- Date: Mon, 8 Jan 2018 10:29:38 -0800
- Subject: 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".
- Authentication-results: sourceware.org; auth=none
- References: <CAAs8HmzJkLiGaUWf9czpNfEejM=uCP=zFvudADEuxsA2wHk+fQ@mail.gmail.com> <CAJimCsGGcXCxQUWD9XGmEHdJ+w01Tr0u29yowA9b16YGHHxMkA@mail.gmail.com> <17cb3295-626f-ba0f-7458-c13eaea24d2b@redhat.com> <CAJimCsE6bZ9VwKTfh9dFvT1HmNb==0Kxh6EJQQWXGoH-U=Epsg@mail.gmail.com> <CAGCO0KhMmBJXuWbb89ZG6tgpVHgmxkE5-xEmMikBjPkVQBDmPA@mail.gmail.com> <CAJimCsFh4c+JgR27i6kVEqexvbfkJJERZ7v7bp6b4JYbR2nUqg@mail.gmail.com> <CAAs8HmyztZxr64OF1q8Vuj=mBeAJXfRS7qssdADDiS5QA3sFpg@mail.gmail.com> <CAMe9rOq0ugokR9crc9yLKGtiJf2bHL7rVQSbQk3PUGXffi2U6Q@mail.gmail.com> <CAMe9rOqb96cF_FOKhrcMv4jZ7yWeKuXWApP9mca15obbwOT5Bg@mail.gmail.com>
- Reply-to: Sriraman Tallam <tmsriram at google dot com>
On Mon, Jan 8, 2018 at 10:27 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> 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.
Thanks!, not yet supported in LLVM. Is this faster than the plain
indirect jump? Any pointers to the patch discussions?
Thanks
Sri
>>
>
> [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.