Re: [PATCH 2/4] x86: Add -mfunction-return=

["Woodhouse, David" <dwmw at amazon dot co dot uk>]

On Sat, 2018-01-13 at 08:09 -0800, H.J. Lu wrote:
> 
> > Again please extend both documentation hunks so it is clear what is purpose
> > of this hack.
> 
> David, can you help here?

On most older CPUs the indirect branch issue is limited to actual
indirect branches.

On Skylake-era CPUs, however, an underflow of the RSB (return stack
buffer) caused by a call/ret imbalance (such as on context switch) will
cause predictions to come from the same problematic branch predictor —
essentially, allowing 'ret' instructions to be targeted by an attacker
in precisely the same way as indirect branches.

Note that there are plenty of other causes for RSB underflow. Like
taking an SMI, which clears the RSB completely. Or various other
things. Including a call stack deeper than 16 function calls.

The -mfunction-return option was an experiment to use the retpoline
approach for 'ret' too. I forget the implementation (I could look
upthread), but essentially it was equivalent to replacing ret with
'pop %r12; jmp __x86_indirect_thunk_r12' so that you *never* deplete
the RSB because of the 'call;ret' trick in the retpoline itself. Hence
your exposure on Skylake was reduced to the possibility of taking an
SMI while *in* the retpoline.

This would, of course, be forcing a mispredict/pipeline stall on every
'ret', rather than only on every indirect branch as in the original
retpoline idea. HJ added the code, but I'm not sure anyone at Intel
ever did actually do the *testing* to establish the performance
characteristics. Dave/Arjan?

For my part, right *now* the kernel doesn't use this option. But then,
we don't have a comprehensive answer for Skylake yet other than "use
the new microcode features". Which are slower than retpoline, but not
as *much* slower on Skylake as they are on other CPUs.

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