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: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Alan Modra <amodra at gmail dot com>, x86-64-abi at googlegroups dot com
- Cc: Cary Coutant <ccoutant at gmail dot com>, Florian Weimer <fweimer at redhat dot com>, Sriraman Tallam <tmsriram at google 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: Sun, 7 Jan 2018 10:10:54 -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>
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.
>
Adding x86-64 psABI group.
Also Florian pointed out, this doesn't work for shadow stack. If you
are really concerned about PLT, you should avoid PLT altogether as
suggested by
https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-secure.pdf
This feature has been implemented in GCC + binutils.
--
H.J.