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

["Chandler Carruth via binutils" <binutils at sourceware dot org>]

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.