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

[Cary Coutant <ccoutant at gmail dot com>]

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

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.

-cary