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".

["Sriraman Tallam via binutils" <binutils at sourceware dot org>]

On Fri, Jan 5, 2018 at 7:00 AM, Ian Lance Taylor <iant@google.com> wrote:
> On Fri, Jan 5, 2018 at 3:42 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 01/05/2018 12:08 AM, Cary Coutant wrote:
>>>>
>>>> * options.h (retpolineplt): New -z option to use retpoline PLT.
>>>> * x86_64.cc (Output_data_plt_x86_64_retpoline): New class.
>>>> (Target_x86_64<64>::do_make_data_plt): Create retpoline PLT when
>>>> the option is used.
>>>> * testsuite/Makefile.am (retpoline_plt_1.sh): New test.
>>>> * testsuite/Makefile.in: Regenerate.
>>>> * testsuite/retpoline_plt_1.sh: New test script.
>>>> * testsuite/retpoline_plt_1.s: New test source.
>>>
>>>
>>> This makes the -z bndplt and -z retpolineplt options mutually
>>> exclusive. Please add a check in options.cc
>>> (General_options::finalize) for this.
>>
>>
>> It's also incompatible with shadow stack support, so the binary marker for
>> that needs to be removed.
>>
>> 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?
>
> As I understand it (and I may not) this option would be appropriate to
> use with dynamically linked programs that hold high value private
> information, run on the same machine as untrusted code, and have some
> communication path with untrusted code.  If the untrusted code can
> cause the trusted program to make indirect branches, it can extract
> information from the trusted program's address space.  No specific
> control is needed over where the untrusted branch goes; the attack
> works by having the untrusted program seed the branch target buffer,
> thus causing the processor to speculatively execute instructions that
> would never normally be executed.  The results of that speculative
> execution, though discarded, will affect the memory cache, and this
> can be used to read the address space of the trusted program.  The
> attack only works if there is some way to cause the trusted program to
> execute an indirect branch; for many programs the PLT provides such a
> mechanism, as many communication paths with the trusted program will
> cause the trusted program to make some sort of libc call.
>
> It seems to me that it would be appropriate to use this option with
> programs like web browsers and ssh-agent, which are long-lived, hold
> high value private information, and by the nature of their operation
> must communicate with untrusted code.

Thanks for the summary!

>
> The change is clearly extremely costly for programs that spend all of
> their time making calls through the PLT.  I doubt that describes the
> kinds of programs that need to worry about this vulnerability.
>
>
>> If we think this is a problem that needs to be fixed, we should remove the
>> indirect call altogether, and have the dynamic linker generate a direct call
>> at load time.  There are few constraints associated with that (4 GiB total
>> application + DSO size, some SELinux users will unhappy, lack of lazy
>> binding support), but at least it can be turned on in practice.

How practical is this really for 64-bit address space where libc is
not mapped close to the binary.  We are looking at this but this if
the call is beyond 4G which is more often the case for shared object
calls, like you noted, this will not work.

>
> I agree that that is a good idea.  If we can make that change in the
> dynamic linker then after a few years, when we can assume that the
> updated dynamic linker is deployed everywhere, then we can discard
> this linker option.  Of course, I expect that processors will be
> modified to prevent this attack over time as well.
>
> Ian