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: "Ian Lance Taylor via binutils" <binutils at sourceware dot org>
- To: Sriraman Tallam <tmsriram at google 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>
- Date: Fri, 5 Jan 2018 16:46:38 -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> <CAKOQZ8wjtV0ZEH4trKyDXY7+bK_csk9jyRQsY6+yjhUsj9bDYQ@mail.gmail.com> <CAAs8HmyfCBGJ=qe97rUi7PCA6XQtjCip50615N4mKCZm8y2G0g@mail.gmail.com>
- Reply-to: Ian Lance Taylor <iant at google dot com>
On Fri, Jan 5, 2018 at 4:03 PM, Sriraman Tallam <tmsriram@google.com> wrote:
>
> On Fri, Jan 5, 2018 at 3:52 PM, Ian Lance Taylor <iant@google.com> wrote:
>> On Fri, Jan 5, 2018 at 3:28 PM, Cary Coutant <ccoutant@gmail.com> wrote:
>>>
>>>> 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.
>>>
>>> That would involve moving the PLT into writable memory, and is a much
>>> bigger change than I'd want to see for what should be a temporary
>>> mitigation strategy.
>>
>> The dynamic linker could mprotect the PLT to be writable, resolve all
>> the references (as with LD_BIND_NOW=1), and then mprotect the PLT to
>> be non-writable again. That would all happen before the program
>> actually starts, so it would be safe.
>
> This looks very similar to how text relocations would be handled,
> except that they are restricted to the .plt section here. Wouldn't
> that mean we would suffer from the problems of TEXTREL which is not
> very desired as far as I understand? Maybe I understood this wrong.
Yes, in this scheme we would want to make sure that the PLT was on a
separate page by itself.
Ian