[llvm-dev] retpoline mitigation and 6.0

[Chandler Carruth via llvm-dev]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180207/7afe665c/attachment.html>