llvm dev - Feb 2018 - retpoline mitigation and 6.0

On Wed, 2018-02-07 at 00:26 +0000, Chandler Carruth
wrote:
> On Tue, Feb 6, 2018 at 4:16 PM Chandler Carruth <chandlerc at google.com
> > wrote:
> > On Tue, Feb 6, 2018 at 2:56 PM David Woodhouse <dwmw2 at
infradead.org
> > > wrote:
> > > At this point, what we really want is for identical thunks to
> > > have identical names — just like we do for builtins and other
> > > stuff, to avoid having differences between clang and GCC which
> > > just end up seeming capricious and being hard to work around.
> > > Having matching command line options would be a bonus, but
isn't
> > > imperative.
> > > 
> > After talking to several others (to make sure we don't have to do
> > this whole thing yet again) we'll change the external thunk names
> > to match what GCC is using. Hopefully this doesn't come back to
> > bite us. =]
> > 
> What name do we use for when the target address is pushed onto the
> stack? What are the semantics? Is there a spec anywheere?
> 
> LLVM only needs this on 32-bit x86, but we do kind of need an answer
> before we update all of our branches with new names....
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180207/a44dbf7b/attachment.html>
-------------- 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/a44dbf7b/attachment.bin>

On Tue, Feb 6, 2018 at 4:32 PM David Woodhouse <dwmw2 at infradead.org>
wrote:
>
>
> On Wed, 2018-02-07 at 00:26 +0000, Chandler Carruth wrote:
>
> On Tue, Feb 6, 2018 at 4:16 PM Chandler Carruth <chandlerc at
google.com>
> wrote:
>
> On Tue, Feb 6, 2018 at 2:56 PM David Woodhouse <dwmw2 at
infradead.org>
> wrote:
>
> At this point, what we really want is for identical thunks to have
> identical names — just like we do for builtins and other stuff, to avoid
> having differences between clang and GCC which just end up seeming
> capricious and being hard to work around. Having matching command line
> options would be a bonus, but isn't imperative.
>
>
> After talking to several others (to make sure we don't have to do this
> whole thing yet again) we'll change the external thunk names to match
what
> GCC is using. Hopefully this doesn't come back to bite us. =]
>
>
> What name do we use for when the target address is pushed onto the stack?
> What are the semantics? Is there a spec anywheere?
>
> LLVM only needs this on 32-bit x86, but we do kind of need an answer
> before we update all of our branches with new names....
>
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180207/74881529/attachment.html>

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>