This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]