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:2.139 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site