[PATCH] D41723: Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre..

[Chandler Carruth via Phabricator via llvm-commits]

chandlerc added a comment.

In https://reviews.llvm.org/D41723#967518, @zachriggle wrote:

> Pardon my unsolicited comment, but it seems to me that using a "retpoline" will have two unintended negative side-effects:
>
> 1. It will ~neuter Control Flow Integrity by providing a "universal" gadget that pulls a call target off the stack and is allowed to call anything


I don't really follow...

Generally, CFI is in the business of preventing arbitrary control flow transfers. So if it is working, you can't jump to a gadget even if you have one.

And the retpoline is no more or less of a gadget than you had before. Before you had something equivalent to `jmpq (%r11)`, now you have a retpoline that does the same thing. Both are viable gadgets, and if you can steer control flow to them they will transfer to an arbitrary location.

Also, I should note that LLVM has CFI mitigations, and they should play nice with this. It will check the target *before* calling the retpoline, just as it would check the target before doing the actual indirect call. We're even looking at ways to use CFI to make the overhead of retpoline much lower. While CFI introduces its own overheads, the overhead from CFI -> CFI+retpoline might be much lower than normal -> normal+retpoline. And you'll get CFI. =]

> 2. It will break performance-counter-based ROP detection

Almost certainly. But what else can we do?


https://reviews.llvm.org/D41723