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:04 AM, Sriraman Tallam <tmsriram@google.com> wrote:
> Hello HJ,
>
> On Sun, Jan 7, 2018 at 10:10 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> 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.
>
> 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
at all.

-- 
H.J.