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

[Ingo Molnar]

* Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:

> 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.

Ok, indeed, that's fair enough.

Thanks,

	Ingo