Home Original page

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

Florian Weimer fw@deneb.enyo.de
Mon Jan 8 08:09:00 GMT 2018 
* Cary Coutant:

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

The “supposedly” bit irks me.  Using RET for indirect jumps isn't new.
They have been used on in the i386 dynamic linker for a long, long
time because there is no reserved register which the PLT stub can use
to store the target address.  (The GNU ABI supports three integer
register arguments, and the remining registers are either
special-purpose or callee-saved.)  As a result, CPUs might already
have logic to recognize non-returning RETs.

It's also not clear to me why the PAUSE loop would be preferable to a
single UD2 or CPUID instruction.

In i386 mode, the CPU does not prefetch through far jumps.  Does such
prefetching occur in x86-64 mode?  If not, why not use a far jump?

Is there an expectation that the retpoline does something to the
caller or callee as far as return stack caching is concerned?

It's also not clear to me that a DSO boundar equals a trust boundary.
For a JIT, the indirect calls which need protecting are likely
someplace else, I assume.

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

I expect that compiler support for indirect branch rewriting together
with -fno-plt is sufficient.  There is simply no need to put any code
into binutils at this point.
More information about the Binutils mailing list