* Peter Zijlstra <[email protected]> wrote:
> On Mon, Oct 21, 2019 at 11:01:04AM +0200, Ingo Molnar wrote: > > > > * Peter Zijlstra <[email protected]> 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) <[email protected]> > > > --- > > > 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
