Messages in this thread | | | Date | Wed, 13 Oct 2021 14:49:07 -0700 | From | Josh Poimboeuf <> | Subject | Re: [PATCH 4/9] x86/alternative: Implement .retpoline_sites support |
| |
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
| |