Re: [PATCH 4/9] x86/alternative: Implement .retpoline_sites support

[Josh Poimboeuf]

On Wed, Oct 13, 2021 at 11:20:02PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 13, 2021 at 01:39:27PM -0700, Josh Poimboeuf wrote:
> > On Wed, Oct 13, 2021 at 02:22:21PM +0200, Peter Zijlstra wrote:
> > > +static int patch_retpoline(void *addr, struct insn *insn, u8 *bytes)
> > > +{
> > > +	void (*target)(void);
> > > +	int reg, i = 0;
> > > +
> > > +	if (cpu_feature_enabled(X86_FEATURE_RETPOLINE))
> > > +		return -1;
> > 
> > Better to do this check further up the call stack in apply_retpolines()
> > before looping through all the call sites?
> 
> In fact, I've pushed it further down, in order to always validate the
> absense of rsp.
> 
> > > +
> > > +	target = addr + insn->length + insn->immediate.value;
> > > +	reg = (target - &__x86_indirect_thunk_rax) /
> > > +	      (&__x86_indirect_thunk_rcx - &__x86_indirect_thunk_rax);
> > > +
> > > +	if (WARN_ON_ONCE(reg & ~0xf))
> > > +		return -1;
> > 
> > It would be more robust and less magical to just have a basic lookup
> > table array which converts a thunk address to a reg.  Then you can just
> > avoid all the safety checks because it's no longer insane ;-)
> 
> Andrew suggested the reverse lookup to validate. That should give the
> same robustness but lacks the linear lookup.

So you've got a WARN_ON_ONCE, a BUG_ON, and a too-deep feature check,
all in the name of supporting this scheme.  ok...

If performance of the linear lookup were a real concern then you could
just put rax and r11 at the beginning of the array.

-- 
Josh