llvm dev - Feb 2018 - retpoline mitigation and 6.0

On Tue, Feb 6, 2018 at 2:56 PM David Woodhouse <dwmw2 at infradead.org>
wrote:
> On Tue, 2018-02-06 at 22:08 +0000, Chandler Carruth wrote:
>
> So, I was waiting to hear a definitive response on whether using aliases
> is hard, and didn't see one here, which is why I haven't responded
further.
>
> However, a colleauge pointed me at an LKML thread where it seems there
> *is* a definitive response?
>
>
> Aliases are hard when the compiler is directly emitting calls to a
> function which is exported to modules, yet the compiler and the kernel
> disagree on what the symbol is actually called.
>
> I spent a happy Sunday evening in a hotel room a few weeks ago, trying to
> make them work before telling the GCC folk "screw it this is too
horrible
> please keep the symbol name as it is".
>
Nah, this is plenty definitive for me. ;]

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. =]

We'll also make sure those patches get backported too so that no released
versions have the old behavior.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180207/07996e2b/attachment.html>

On Wed, 2018-02-07 at 00:16 +0000, Chandler Carruth
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.
> =]
> 
> We'll also make sure those patches get backported too so that no
> released versions have the old behavior.
Thank you.
For reference, is there a way to turn *off* the retpoline which has
been enabled on the command line? 
For init functions which run only at startup before any attacker can be
in the system, we currently mark the function
__attribute__((indirect_thunk("keep"))). Is there a clang equivalent?
It's not particularly important; a minor optimisation we can live
without if we have to. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180207/a6b35769/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/a6b35769/attachment.bin>

Can you file a bug to track either explaining how to do that or
implementing it?

My guess is that it doesn't work yet, will be made to work by a future
change that has already been proposed but not implemented...

Also, I'm going to hypothesize this will introduce yet another divergence
between GCC and Clang. Not sure there is anyway to avoid that at this
point. (We still have the significant divergence in that GCC supports
thunking in ways that LLVM doesn't, and that in turn changes several
aspects of the feature design.)

On Tue, Feb 6, 2018 at 4:21 PM David Woodhouse <dwmw2 at infradead.org>
wrote:
>
>
> On Wed, 2018-02-07 at 00:16 +0000, Chandler Carruth 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. =]
>
> We'll also make sure those patches get backported too so that no
released
> versions have the old behavior.
>
>
> Thank you.
>
> For reference, is there a way to turn *off* the retpoline which has been
> enabled on the command line?
>
> For init functions which run only at startup before any attacker can be in
> the system, we currently mark the function
> __attribute__((indirect_thunk("keep"))). Is there a clang
equivalent?
>
> It's not particularly important; a minor optimisation we can live
without
> if we have to.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180207/f91222a1/attachment-0001.html>

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

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>