Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

[David Woodhouse]

On Tue, 2018-01-23 at 11:23 +0100, Ingo Molnar wrote:
> * David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
> 
> > 
> > > 
> > > On SkyLake this would add an overhead of maybe 2-3 cycles per function call andÂ
> > > obviously all this code and data would be very cache hot. Given that the averageÂ
> > > number of function calls per system call is around a dozen, this would be _much_Â
> > > faster than any microcode/MSR based approach.
> > That's kind of neat, except you don't want it at the top of the
> > function; you want it at the bottom.
> > 
> > If you could hijack the *return* site, then you could check for
> > underflow and stuff the RSB right there. But in __fentry__ there's not
> > a lot you can do other than complain that something bad is going to
> > happen in the future. You know that a string of 16+ rets is going to
> > happen, but you've got no gadget in *there* to deal with it when it
> > does.
>
> No, it can be done with the existing CALL instrumentation callback thatÂ
> CONFIG_DYNAMIC_FTRACE=y provides, by pushing a RET trampoline on the stack fromÂ
> the CALL trampoline - see my previous email.

Yes, that's a neat solution.

> > 
> > HJ did have patches to turn 'ret' into a form of retpoline, which I
> > don't think ever even got performance-tested.
> Return instrumentation is possible as well, but there are two major drawbacks:
> 
> Â- GCC support for it is not as widely available and return instrumentation isÂ
> ÂÂÂless tested in Linux kernel contexts

Hey, we're *already* making people upgrade their compiler, and HJ
apparently never sleeps. So don't actually be held back too much by
that consideration. If it could be better done with GCC help, we really
*can* explore that.

> Â- a major point of my suggestion is that CONFIG_DYNAMIC_FTRACE=y is alreadyÂ
> ÂÂÂenabled in distros here and today, so the runtime overhead to non-SkyLake CPUsÂ
> ÂÂÂwould be literally zero, while still allowing to fix the RSB vulnerability onÂ
> ÂÂÂSkyLake.

Sure. You still have a few holes to fix (or declare acceptable) to
bring it to the full coverage of the IBRS solution, and it's still
possible that by the time it's complete it's approaching the ick factor
of IBRS, but I'd love to see it.

Attachment: smime.p7s
Description: S/MIME cryptographic signature