[llvm-dev] retpoline mitigation and 6.0

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Tue Feb 6 16:24:19 PST 2018

Can you file a bug to track either explaining how to do that or
implementing it?

My guess is that it doesn't work yet, will be made to work by a future
change that has already been proposed but not implemented...

Also, I'm going to hypothesize this will introduce yet another divergence
between GCC and Clang. Not sure there is anyway to avoid that at this
point. (We still have the significant divergence in that GCC supports
thunking in ways that LLVM doesn't, and that in turn changes several
aspects of the feature design.)

On Tue, Feb 6, 2018 at 4:21 PM David Woodhouse <dwmw2 at infradead.org> wrote:

> On Wed, 2018-02-07 at 00:16 +0000, Chandler Carruth 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. =]
> We'll also make sure those patches get backported too so that no released
> versions have the old behavior.
> Thank you.
> For reference, is there a way to turn *off* the retpoline which has been
> enabled on the command line?
> For init functions which run only at startup before any attacker can be in
> the system, we currently mark the function
> __attribute__((indirect_thunk("keep"))). Is there a clang equivalent?
> It's not particularly important; a minor optimisation we can live without
> if we have to.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180207/f91222a1/attachment-0001.html>

More information about the llvm-dev mailing list