linux-kernel - Re: [PATCH v4 10/16] x86/alternative: Shrink text_poke

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191021090104.GB102207@gmail.com>
Date:   Mon, 21 Oct 2019 11:01:04 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org, rostedt@...dmis.org,
        mhiramat@...nel.org, bristot@...hat.com, jbaron@...mai.com,
        torvalds@...ux-foundation.org, tglx@...utronix.de,
        namit@...are.com, hpa@...or.com, luto@...nel.org,
        ard.biesheuvel@...aro.org, jpoimboe@...hat.com, jeyu@...nel.org
Subject: Re: [PATCH v4 10/16] x86/alternative: Shrink text_poke_loc


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