[llvm-dev] retpoline mitigation and 6.0

[Guenter Roeck via llvm-dev]

On 02/06/2018 10:20 PM, Chandler Carruth wrote:
> I've landed the patch in r324449.
> 
> Before we merge this into two different Clang release branches and almost immediately release one of them, I would really like someone to confirm that this patch works well with the Linux kernel. David, if you're up for that, it would be great. Alternatively, Guenter or someone else here can help.
> 
I'll try to test it today.

Guenter

> On Tue, Feb 6, 2018 at 5:59 PM Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote:
> 
>     The patch is up for review here: https://reviews.llvm.org/D42998
> 
>     On Tue, Feb 6, 2018 at 4:58 PM Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote:
> 
>         Also, could you patch and test Clang with the Linux kernel after I make this change? I'd like to know that we actually successfully call the correct thunks and that they behave correctly. I'm not super worried, but good to  actually get this right. I'm am slightly more worried about the stack-based retpoline than the register ones just due to the overall lower amount of testing we've had there.
> 
>         On Tue, Feb 6, 2018 at 4:56 PM Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote:
> 
>             On Tue, Feb 6, 2018 at 4:46 PM David Woodhouse <dwmw2 at infradead.org <mailto:dwmw2 at infradead.org>> wrote:
> 
>                 On Wed, 2018-02-07 at 00:36 +0000, Chandler Carruth wrote:
> 
>                  > >
>                  > > That would be __x86_indirect_thunk but the kernel doesn't use it.
>                  > > We use -mindirect-branch-register and only ever expect the compiler
>                  > > to use the register versions which are CET-compatible.
>                  > >
>                  > > However, in at least one case in the 32-bit kernel we do emit the
>                  > > old ret-equivalent retpoline inline, because there literally wasn't
>                  > > a single register we could use (yay x86).
>                  > >
>                  > > I would definitely consider ditching our use of -mindirect-thunk-
>                  > > register with GCC for 32-bit and exporting the
>                  > > __x86_indirect_thunk, to be consistent if that's what clang wants
>                  > > to do.
>                  > >
>                  > :: sigh :: is there no way to change the name?
>                  >
>                  > We use a "push" suffix to reduce ambiguity about what convention is
>                  > expected here.... But I guess we can just use the base name if that's
>                  > already shipped.
> 
>                 It has indeed already shipped in GCC 7.3; sorry. It had no
>                 disambiguation in its name because it was the original retpoline,
>                 before we realised that CET would break things.
> 
>                 The other thing to keep an eye on is the *return* thunk, which might
>                 end up being needed on Skylake-era CPUs. See the thread at
>                 https://lkml.org/lkml/2018/2/4/147
> 
> 
>             I'm strongly of the opinion that I think Arjan expressed:
> 
>             - retpoline alone is probably fine with sufficient RSB stuffing patches in the kernel
>             - if some folks are worried about the security risk here and running on SKX, they should use IBRS.
> 
>             Given the speed of IBRS on SKX and the complexity & runtime hit of thunking ret, I really don't see a good motivation for us teaching the compiler how to do this.
>