[llvm-dev] retpoline mitigation and 6.0
Chandler Carruth via llvm-dev
llvm-dev at lists.llvm.org
Tue Feb 6 16:36:23 PST 2018
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>
> On Tue, Feb 6, 2018 at 2:56 PM David Woodhouse <dwmw2 at infradead.org>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev