<div dir="ltr">Also, could you patch and test Clang with the Linux kernel after I make this change? I'd like to know that we actually successfully call the correct thunks and that they behave correctly. I'm not super worried, but good to  actually get this right. I'm am slightly more worried about the stack-based retpoline than the register ones just due to the overall lower amount of testing we've had there.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 6, 2018 at 4:56 PM Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Feb 6, 2018 at 4:46 PM David Woodhouse <<a href="mailto:dwmw2@infradead.org" target="_blank">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 Wed, 2018-02-07 at 00:36 +0000, Chandler Carruth wrote:<br>
<br>
> ><br>
> > That would be __x86_indirect_thunk but the kernel doesn't use it.<br>
> > We use -mindirect-branch-register and only ever expect the compiler<br>
> > to use the register versions which are CET-compatible.<br>
> ><br>
> > However, in at least one case in the 32-bit kernel we do emit the<br>
> > old ret-equivalent retpoline inline, because there literally wasn't<br>
> > a single register we could use (yay x86).<br>
> ><br>
> > I would definitely consider ditching our use of -mindirect-thunk-<br>
> > register with GCC for 32-bit and exporting the<br>
> > __x86_indirect_thunk, to be consistent if that's what clang wants<br>
> > to do.<br>
> ><br>
> :: sigh :: is there no way to change the name?<br>
><br>
> We use a "push" suffix to reduce ambiguity about what convention is<br>
> expected here.... But I guess we can just use the base name if that's<br>
> already shipped.<br>
<br>
It has indeed already shipped in GCC 7.3; sorry. It had no<br>
disambiguation in its name because it was the original retpoline,<br>
before we realised that CET would break things.<br>
<br>
The other thing to keep an eye on is the *return* thunk, which might<br>
end up being needed on Skylake-era CPUs. See the thread at<br>
<a href="https://lkml.org/lkml/2018/2/4/147" rel="noreferrer" target="_blank">https://lkml.org/lkml/2018/2/4/147</a></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>I'm strongly of the opinion that I think Arjan expressed:</div><div><br></div><div>- retpoline alone is probably fine with sufficient RSB stuffing patches in the kernel</div><div>- if some folks are worried about the security risk here and running on SKX, they should use IBRS.</div><div><br></div><div>Given the speed of IBRS on SKX and the complexity & runtime hit of thunking ret, I really don't see a good motivation for us teaching the compiler how to do this.</div></div></div></blockquote></div>