llvm dev - Feb 2018 - retpoline mitigation and 6.0

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180207/688dcb7d/attachment.bin>

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>

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

On 6 February 2018 at 19:56, Chandler Carruth via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> 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.
As far as Clang-compiled kernels are concerned I suspect FreeBSD has
the biggest footprint, so this is very important to us. I'm still
waiting on feedback about this point (retpoline vs IBRS on SKX), but I
expect we will go down the path that you describe above.

We have yet to implement retpoline changes in kernel asm but will do
so soon, so very much want to have a final implementation.

It also seems that we still have a lone register-indirect call
remaining (coming from a C source file) when everything is compiled
with -mretpoline; I'm looking into it.