[llvm-dev] retpoline mitigation and 6.0

[Chandler Carruth via llvm-dev]

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>