[llvm-dev] retpoline mitigation and 6.0

[Guenter Roeck via llvm-dev]

On Wed, Feb 07, 2018 at 06:20:40AM +0000, 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.
> 
It works pretty well for me, except for an endless sequence of

./include/linux/init.h:134:6: warning:
	unknown attribute 'indirect_branch' ignored [-Wunknown-attributes]

This is due to

#define __noretpoline __attribute__((indirect_branch("keep")))

which was introduced with upstream commit 66f793099a636 ("x86/retpoline:
Avoid retpolines for built-in __init functions") a couple of days ago.

Guenter

> On Tue, Feb 6, 2018 at 5:59 PM Chandler Carruth <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>
> > 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>
> >> wrote:
> >>
> >>> On Tue, Feb 6, 2018 at 4:46 PM David Woodhouse <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.
> >>>
> >>