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

[Venkataramanan Kumar via Phabricator via llvm-commits]

venkataramanan.kumar.llvm added a comment.

In https://reviews.llvm.org/D41723#976776, @jyknight wrote:

> Per kernel https://marc.info/?l=linux-kernel&m=151580566622935&w=2 and gcc https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01059.html, it seems AMD needs there to be an lfence in the speculation trap (and the pause is not useful for them, but does no harm). There seems to be some speculation (but no confirmation yet?) that pause *is* necessary vs lfence on intel. So in order to work generically, they seem to be suggesting using both instructions:
>
>   loop:
>     pause
>     lfence
>     jmp loop
>
>
> Some more links
>  https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01209.html
>  and final patch:
>  https://github.com/gcc-mirror/gcc/commit/a31e654fa107be968b802786d747e962c2fcdb2b




In https://reviews.llvm.org/D41723#976776, @jyknight wrote:

> Per kernel https://marc.info/?l=linux-kernel&m=151580566622935&w=2 and gcc https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01059.html, it seems AMD needs there to be an lfence in the speculation trap (and the pause is not useful for them, but does no harm). There seems to be some speculation (but no confirmation yet?) that pause *is* necessary vs lfence on intel. So in order to work generically, they seem to be suggesting using both instructions:
>
>   loop:
>     pause
>     lfence
>     jmp loop
>
>
> Some more links
>  https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01209.html
>  and final patch:
>  https://github.com/gcc-mirror/gcc/commit/a31e654fa107be968b802786d747e962c2fcdb2b


Yes for AMD,  we require "lfence" instruction after the "pause" in the "retpoline" loop filler.  This solution has already been accepted in GCC and Linux kernel.
Can you please do the same in LLVM as well?


Repository:
  rL LLVM

https://reviews.llvm.org/D41723