lkml.org 
[lkml]   [2019]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 10/16] x86/alternative: Shrink text_poke_loc

* Peter Zijlstra <peterz@infradead.org> 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@infradead.org>
> ---
> 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 ...

Thanks,

Ingo

\
 
 \ /
  Last update: 2019-10-21 11:02    [W:0.519 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site