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: Alan Modra <amodra at gmail dot com>
- Cc: Cary Coutant <ccoutant at gmail dot com>, Florian Weimer <fweimer at redhat dot com>, binutils <binutils at sourceware dot org>, Chandler Carruth <chandlerc at google dot com>, 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>, Bill Schmidt <wschmidt at us dot ibm dot com>
- Date: Mon, 8 Jan 2018 10:10:03 -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> <20180106025327.GF3071@bubble.grove.modra.org>
- Reply-to: Sriraman Tallam <tmsriram at google dot com>
Hi Alan,
On Fri, Jan 5, 2018 at 6:53 PM, Alan Modra <amodra@gmail.com> wrote:
> On Fri, Jan 05, 2018 at 03:28:34PM -0800, Cary Coutant wrote:
>> > It's also incompatible with shadow stack support, so the binary marker for
>> > that needs to be removed.
>>
>> Ugh. But that marker shouldn't be set in the first place, since this
>> linker option is useful only in conjunction with a corresponding
>> compiler option.
>>
>> > I don't think this is the right approach at all. What is this trying to
>> > accomplish? What kind of speculation barrier does this implement on current
>> > CPUs? Isn't this *extremely* costly?
>>
>> Supposedly, this strategy aims to disable branch prediction for all
>> indirect branches in a piece of code, so that attackers cannot use
>> branch predictor training to force the speculative execution of any
>> available "gadgets" in the target code. I haven't yet seen any claims
>> where branch predictor training by itself can be exploited -- it's
>> simply one way to exploit the cache side channel vulnerabilities.
>
> I don't think it's just the victim code. It seems to me that you'd
> need to disable indirect branch prediction for all indirect branches
> in the victim address space. So it won't be sufficient to simply
> relink the app with fancy PLT call code. You'd need to relink *all*
> libraries that make PLT calls, including libc.so, too. (libc PLT
> calls to __tls_get_addr, calloc and any ifunc come to mind as possible
> attack vectors.) And of course recompile everything to mitigate any
> inline function pointer calls.
>
> Unless I'm missing something, this makes the fancy PLT mitigation
> unworkable in practice. You will definitely not want a slow shared
> libc, libstdc++ etc. to be used by all applications. So build a set
> of hardened static libraries and link them into your hardened app.
> No PLT calls involved, and thus no PLT mitigation needed.
Thanks for pointing these out. We are working on mitigating the some
of the slowness from shared libraries. Here are some of the things we
considered:
* Static linking is out of question since we need to use PIE to enable
ASLR and PIE+static linking is not supported.
* We are working on something like partial static linking where we
still link to libc dynamically but statically link hot memops like
memcpy, memcmp etc. to avoid PLT + ifunc penalty for them.
* You are right that we would still have to re-build libc.so to use
retpoline but hopefully with some variant of partial static linking we
may be able to keep hot libc calls from incurring the penalty.
Thanks
Sri
>
> --
> Alan Modra
> Australia Development Lab, IBM