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".
Mon Jan 8 18:20:00 GMT 2018
On Mon, Jan 8, 2018 at 10:04 AM, Sriraman Tallam <email@example.com> wrote:
> Hello HJ,
> On Sun, Jan 7, 2018 at 10:10 AM, H.J. Lu <firstname.lastname@example.org> wrote:
>> On Fri, Jan 5, 2018 at 6:53 PM, Alan Modra <email@example.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
>> This feature has been implemented in GCC + binutils.
> Are you referring to the no-plt feature? If that is the case, I
> contributed to the -fno-plt option in GCC and also in LLVM and the
> gold patches to binutils, and I did bring this up. The problem is
> there is still an indirect jmp directly from the callsite via the GOT
> and hence it is still exposed to the attack.
Do you have an example? With -fno-PLT, PLT shouldn't be used
More information about the Binutils