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: "Sriraman Tallam via binutils" <binutils at sourceware dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Cary Coutant <ccoutant at gmail dot com>, Chandler Carruth <chandlerc at google dot com>, binutils <binutils at sourceware dot org>, 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: Mon, 8 Jan 2018 10:35:58 -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> <CAGCO0KhMmBJXuWbb89ZG6tgpVHgmxkE5-xEmMikBjPkVQBDmPA@mail.gmail.com> <CAJimCsFh4c+JgR27i6kVEqexvbfkJJERZ7v7bp6b4JYbR2nUqg@mail.gmail.com> <CAAs8HmyztZxr64OF1q8Vuj=mBeAJXfRS7qssdADDiS5QA3sFpg@mail.gmail.com> <e7ca7f34-08bf-5024-568a-5f47e31a998a@redhat.com>
- Reply-to: Sriraman Tallam <tmsriram at google dot com>
On Mon, Jan 8, 2018 at 10:23 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 01/08/2018 07:19 PM, Sriraman Tallam wrote:
>>
>> * Regarding what HJ said, unless I misunderstood, I believe he is
>> referring to using fno-plt. We considered that but the problem is the
>> indirect jump still exists, but now at the call site. The mitigation
>> would still be necessary at the call site as it is still exposed to
>> the attack.
>
>
> But you'll have to patch GCC anyway to change the opcode sequence for
> indirect jumps (just think of vtable dispatch), and then -fno-plt most
> likely would move the dynamic linker and PLT stubs completely out of the
> equation.
* Yes, you are right and we did work to patch LLVM with this,
https://reviews.llvm.org/D41723
* If we use fno-plt, we could just do the work of patching the call
site in the compiler and completely avoid the linker. We did note
that, but the downside is losing out on lazy binding which could
affect mobile applications where I believe this is pretty crucial, it
reduces start-up time significantly. HJ's patch might change this and
I have not taken a look at this yet.
* We did consider these and it did not seem very hard to patch the PLT.
Your thoughts?
Thanks
Sri
>
> A DSO boundary is not a trust boundary, so this is not comparable to the
> kernel situation at all. For a generic solution, you need to rewrite all
> indirect function calls.
>
> Thanks,
> Florian