[llvm-dev] retpoline mitigation and 6.0

[Chandler Carruth via llvm-dev]

On Fri, Feb 2, 2018 at 4:03 PM David Woodhouse <dwmw2 at infradead.org> wrote:

> On Thu, 2018-02-01 at 10:10 +0100, Hans Wennborg via llvm-dev wrote:
> >
> > I saw the retpoline mitigation landed in r323155. Are we ready to
> > merge this to 6.0, or are there any open issues that we're waiting
> > for? Also, were there any followups I should know about? Also,
> > release notes please :-)
>
> Eep, please can we keep the command line option for clang and the thunk
> ABI matching what GCC, the Linux kernel and Xen are all doing?
>
> To say that I am not stunningly keen on
> https://lkml.org/lkml/2018/2/2/975 would be a bit of an
> understatement...


Two aspects to this...

One, we're somewhat reluctant to guarantee an ABI here. At least I am.
While we don't *expect* rampant divergence here, I don't want this to
become something we cannot change if there are good reasons to do so. We've
already changed the thunks once based on feedback (putting LFENCE after the
PAUSE).

Given that we don't want this to be a guaranteed part of the ABI, I really
want the thunk names to be specific about which implementation is being
used. For example, if we come up with a new, better thunk interface, we
would want to give it a new name (even if it were just a suffix of "2") so
that we don't get runtime failures. Since LLVM and GCC can't possible
release in sync, IMO they *should* use different names. I asked the GCC
developers to include 'gcc' in the name, but at least the person I asked
was not at all receptive.


Two, I actually agree with you about the command line flags. I asked for it
to be '-mretpoline'. I think a short, clear flag is really best, and we've
very publicly documented this technique as 'retpoline'. But the GCC
community has a fairly different design AFAICT... The only embedded thunks
the offer are inline (ours are always out-of-line, even if they aren't
external). Also, they support thunking indirect branches that we don't:
ret. Our feature really is oriented around exposing the retpoline
mitigation, and I don't think there is any demand for the complexity that
would be entailed by generalizing it further. But I'm sure the GCC folks
have a very reasonably different perspective here that make them prefer a
quite different feature (they can thunk rets) and naming scheme.


So I don't really know how to fix this. I think there are reasonable
arguments in each direction. IMO, the easiest improvement would be for GCC
to add command line aliases spelled using 'retpoline' for the specific use
case, but keep the more general commandline interface for which they have
reasonable use cases.

The naming thing I think is essentially by-design so that if we (or you)
need to split apart the implementation, there are distinct names available.
Until then, aliases seem very cheap to maintain?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180203/223d1983/attachment.html>