<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Feb 2, 2018 at 4:03 PM David Woodhouse <<a href="mailto:dwmw2@infradead.org">dwmw2@infradead.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 2018-02-01 at 10:10 +0100, Hans Wennborg via llvm-dev wrote:<br>
><br>
> I saw the retpoline mitigation landed in r323155. Are we ready to<br>
> merge this to 6.0, or are there any open issues that we're waiting<br>
> for? Also, were there any followups I should know about? Also,<br>
> release notes please :-)<br>
<br>
Eep, please can we keep the command line option for clang and the thunk<br>
ABI matching what GCC, the Linux kernel and Xen are all doing?<br>
<br>
To say that I am not stunningly keen on<br>
<a href="https://lkml.org/lkml/2018/2/2/975" rel="noreferrer" target="_blank">https://lkml.org/lkml/2018/2/2/975</a> would be a bit of an<br>
understatement...</blockquote><div><br></div><div>Two aspects to this...</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>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?</div></div></div>