llvm dev - Feb 2018 - retpoline mitigation and 6.0

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>

On Sat, 2018-02-03 at 01:08 +0000, Chandler Carruth
wrote:
> 
> 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. =/
Using the *external* thunk in order to provide their own? While
claiming it isn't an ABI? That seems... odd.

Nobody cares what you call it when you're doing it inline or in a
COMDAT section. It's *only* the external thunk where it absolutely
*does* become an ABI, where we care about consistency.
-------------- 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/3c4c4877/attachment.bin>

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?

I'm really looking for clear direction: we can try to implement custom
naming, but it will add undesirable complexity to the compiler. Do we need
it for the kernel? I have to ask because I genuinely don't know what is or
isn't reasonable in the kernel.

On Sat, Feb 3, 2018 at 6:36 AM David Woodhouse <dwmw2 at infradead.org>
wrote:
> It's *only* the external thunk where it absolutely
> *does* become an ABI, where we care about consistency.

In the future, if there is such a powerful need for consistency, it would
be good to actually engage with more than one compiler community. =/ As I
said, I tried to talk to the GCC developers and made no progress but also
heard no strong arguments that this kind of consistency was actually
necessary.

I really do want to produce a feature that addresses the kernel's needs,
but we need to know what they are and have some chance to figure out how to
find a solution that also doesn't cause problems for the compiler. This is
just a note for the future though, the retpoline stuff is above.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180206/cb64b8d9/attachment.html>