llvm dev - Feb 2018 - retpoline mitigation and 6.0

On Fri, Feb 2, 2018 at 4:36 PM David Woodhouse <dwmw2 at infradead.org>
wrote:
> On Sat, 2018-02-03 at 00:23 +0000, Chandler Carruth wrote:
> >
> > Two aspects to this...
> >
> > One, we're somewhat reluctant to guarantee an ABI here. At least I
> > am. While we don't *expect* rampant divergence here, I don't
want
> > this to become something we cannot change if there are good reasons
> > to do so. We've already changed the thunks once based on feedback
> > (putting LFENCE after the PAUSE).
>
> Surely adding the lfence was changing your implementation, not the ABI?
>
> And if we really are talking about the *ABI* not the implementation,
> I'm not sure I understand your concern.
>
> The ABI for each thunk is that it is identical in all respects, apart
> from speculation, to 'jump *\reg'. There's not a lot of scope
for a
> 'v2' of that, surely?
>
While I hope we have converged and never need to chaneg them, when we
started, there was actually a substantially different ABI proposed, and
multiple different ones. So some changes already were needed.

We already have at least one change that has been proposed, but we haven't
decided to pursue yet: a thunk which includes the *load* of the address,
and specifically a collection to handle common repeated patterns of loads
that before retpoline would have folded into addressing modes. And these
would definitely have a different ABI.

>
> I could live with the command-line divergence, although it's
> suboptimal. But *please* since these things also need to be symbols
> exported to loadable modules, can't we keep the thunk names identical?
>
At least for LLVM when not using *external* thunks, we specifically *do not
export* the symbol. As a consequence, DSOs built with two versions of LLVM
(or LLVM and GCC) with different thunk behavior and each will find the
correct thunk. That was a specific part of the design.

While you *can* export your external thunk, that's a choice of the code
defining the thunk.

>
> You can even use __x86_indirect_thunk_\reg for *now* and reserve the
> right to use a different name if you ever do revise the ABI.
>
Maybe I don't understand, but I'm surprised that there is a significant
burden to having aliases for now instead?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180203/26baaa32/attachment.html>

On Sat, 2018-02-03 at 00:51 +0000, Chandler Carruth
wrote:
> While you *can* export your external thunk, that's a choice of the
> code defining the thunk.
The driving force in the kernel is to be able to runtime patch the
thunks away, when running on a CPU or in a mode that doesn't need them.
We really want to have central implementations and have everything use
them.
> > 
> > 
> > You can even use __x86_indirect_thunk_\reg for *now* and reserve the
> > 
> > right to use a different name if you ever do revise the ABI.> >
Maybe I don't understand, but I'm surprised that there is a significant
burden to having aliases for now instead? 
> 
You can make that work within the kernel image itself, and export only
the existing names. It gets somewhat harder to support loadable modules
which attempt to use the thunks by different names to the function
that's exported. I'm not sure how we'd hack up the unresolved
symbols
in the module objects to match the exported symbol names.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180203/0f539d8c/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/20180203/0f539d8c/attachment.bin>

On Fri, Feb 2, 2018 at 4:59 PM David Woodhouse <dwmw2 at infradead.org>
wrote:
>
>
> On Sat, 2018-02-03 at 00:51 +0000, Chandler Carruth wrote:
>
> While you *can* export your external thunk, that's a choice of the code
> defining the thunk.
>
>
> The driving force in the kernel is to be able to runtime patch the thunks
> away, when running on a CPU or in a mode that doesn't need them. We
really
> want to have central implementations and have everything use them.
>
Sure, I can see why for the kernel, this is important. It also gets to
essentially define its ABI however it wants.

For our other users, they specifically don't want this in the ABI (because
they actually have DSOs and other junk being linked together). And yes, we
actually have a decent number of users of this in userspace and outside the
kernel. =/

>
>
> You can even use __x86_indirect_thunk_\reg for *now* and reserve the
> right to use a different name if you ever do revise the ABI.
>
>
> Maybe I don't understand, but I'm surprised that there is a
significant
> burden to having aliases for now instead?
>
>
> You can make that work within the kernel image itself, and export only the
> existing names. It gets somewhat harder to support loadable modules which
> attempt to use the thunks by different names to the function that's
> exported. I'm not sure how we'd hack up the unresolved symbols in
the
> module objects to match the exported symbol names.
>
I had actually wanted to originally have the
'-mretpoline-external-thunk'
flag take a completely custom name for the thunks on the command line.
Unfortunately, that proved remarkably annoying to implement in LLVM (for
pretty silly reasons, but it is what it is). I didn't do that in large part
because it seemed easy for users of external thunks to alias things
themselves.

If the way loadable modules in the kernel work actually makes that quite
hard, we can look again at allowing the external thunks to have a user
controlled name. This seems strictly superior to any kind of agreed-to
naming scheme as it gives you much more control. But it'll be really messy
in LLVM to do[1], so I'd appreciate understanding how important this is for
the kernel.

-Chandler

[1]: Yeah, it really shouldn't be. We are aware that this is a nasty aspect
to how various components of LLVM are wired together and want to have
better infrastructure here. But today, we don't. And especially since all
of this needs to be backported to old versions of Clang and LLVM, we can't
fix that and instead need to work around the existing infrastructure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180203/0dc67d2e/attachment.html>