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: "Chandler Carruth via binutils" <binutils at sourceware dot org>
- To: Cary Coutant <ccoutant at gmail dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, Sriraman Tallam <tmsriram 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: Fri, 5 Jan 2018 18:45:36 -0500
- 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>
- Reply-to: Chandler Carruth <chandlerc at google dot com>
Just to provide some context as one of the leads at Google that has
been working on this class of security mitigation...
On Fri, Jan 5, 2018 at 6:28 PM, Cary Coutant <ccoutant@gmail.com> 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.
>
> Yes, it's costly. I'm hoping that once the cache side channels have
> been closed down, we can forget about this option. As for how badly
> it's needed in the meantime, I don't really know. I get the feeling
> that this particular approach to the exploits is most useful in
> leaking data from a hypervisor into a guest OS; thus, the fix is
> important for cloud-based services. But, given that, I also don't
> really know whether it's really needed for user-level apps that may be
> dynamically linked, or only for the kernel, for which compiler changes
> should be sufficient.
We aren't patching linkers just because we can. ;]
There are classes of security sensitive applications where this kind
of mitigation is essential to fully mitigate the variant #2 of the
speculative execution attacks recently disclosed. We have some of
these and we have a specific need to build them with these
mitigations. We suspect others do as well which is why we worked hard
to share this patch ASAP after disclosure.
>
> BTW, the most informative resource I've found so far is ARM's "Cache
> Speculation Side Channels" white paper, found here:
> https://developer.arm.com/support/security-update/download-the-whitepaper.
>
>> 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.
I also was interested in having the loader generate direct calls but
in addition to the point Cary makes here, there is a further problem
that deploying a loader supporting this is *significantly* harder than
rebuilding your application (which is, itself, quite hard). The new
loader would need to be deployed everywhere even if only a tiny
fraction of applications needed this functionality. We would very much
like a mitigation strategy that we can deploy rapidly in the very few
(but important) cases where it is needed.