[llvm-dev] retpoline mitigation and 6.0

[Chandler Carruth via llvm-dev]

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>