Re: [PATCH v4 10/16] x86/alternative: Shrink text_poke_loc

[Peter Zijlstra]

On Mon, Oct 21, 2019 at 11:01:04AM +0200, Ingo Molnar wrote:
> 
> * Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> 
> > Employ the fact that all text must be within a s32 displacement of one
> > another to shrink the text_poke_loc::addr field. Make it relative to
> > _stext.
> > 
> > This then shrinks struct text_poke_loc to 16 bytes, and consequently
> > increases TP_VEC_MAX from 170 to 256.
> > 
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> > ---
> >  arch/x86/kernel/alternative.c |   23 ++++++++++++++---------
> >  1 file changed, 14 insertions(+), 9 deletions(-)
> > 
> > --- a/arch/x86/kernel/alternative.c
> > +++ b/arch/x86/kernel/alternative.c
> > @@ -937,7 +937,7 @@ static void do_sync_core(void *info)
> >  }
> >  
> >  struct text_poke_loc {
> > -	void *addr;
> > +	s32 rel_addr; /* addr := _stext + rel_addr */
> >  	s32 rel32;
> >  	u8 opcode;
> >  	const u8 text[POKE_MAX_OPCODE_SIZE];
> > @@ -948,13 +948,18 @@ static struct bp_patching_desc {
> >  	int nr_entries;
> >  } bp_patching;
> >  
> > +static inline void *text_poke_addr(struct text_poke_loc *tp)
> > +{
> > +	return _stext + tp->rel_addr;
> > +}
> 
> So won't this complicate the life of the big-address-space gcc model 
> build patches that for purposes of module randomization are spreading the 
> kernel and modules all across the 64-bit address space, where they might 
> not necessarily end up within a ~2GB window?
> 
> Nothing upstream yet, but I remember such patches ...

IIRC what they were doing was allow moving the 2G range further out into
the address space, such that absolute addresses no longer fit in u32 (as
they do now), but they keep the relative displacement in s32. Otherwise
we'll end up with PLT entries all over the place. That is, if we break
the s32 displacement, CALL/JMP.d32 will not longer be able to reach any
other code and we need intermediate trampolines to help them along,
which is pretty shit.