linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Joe Lawrence <joe.lawrence@redhat.com>
To: Russell Currey <ruscur@russell.cc>, linuxppc-dev@lists.ozlabs.org
Cc: live-patching@vger.kernel.org, jniethe5@gmail.com,
	naveen.n.rao@linux.vnet.ibm.com
Subject: Re: [PATCH] powerpc/module_64: Fix livepatching for RO modules
Date: Tue, 7 Dec 2021 09:44:48 -0500	[thread overview]
Message-ID: <d9d9ef2d-4aaa-7d8b-d15e-0452a355c5cf@redhat.com> (raw)
In-Reply-To: <20211123081520.18843-1-ruscur@russell.cc>

On 11/23/21 3:15 AM, Russell Currey wrote:
> Livepatching a loaded module involves applying relocations through
> apply_relocate_add(), which attempts to write to read-only memory when
> CONFIG_STRICT_MODULE_RWX=y.  Work around this by performing these
> writes through the text poke area by using patch_instruction().
> 
> R_PPC_REL24 is the only relocation type generated by the kpatch-build
> userspace tool or klp-convert kernel tree that I observed applying a
> relocation to a post-init module.
> 
> A more comprehensive solution is planned, but using patch_instruction()
> for R_PPC_REL24 on should serve as a sufficient fix.
> 
> This does have a performance impact, I observed ~15% overhead in
> module_load() on POWER8 bare metal with checksum verification off.
> 
> Fixes: c35717c71e98 ("powerpc: Set ARCH_HAS_STRICT_MODULE_RWX")
> Cc: stable@vger.kernel.org # v5.14+
> Reported-by: Joe Lawrence <joe.lawrence@redhat.com>
> Signed-off-by: Russell Currey <ruscur@russell.cc>
> ---
> Intended to be a minimal fix that can go to stable.
> 
>  arch/powerpc/kernel/module_64.c | 30 ++++++++++++++++++++++--------
>  1 file changed, 22 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
> index 6baa676e7cb6..c25ef36c3ef4 100644
> --- a/arch/powerpc/kernel/module_64.c
> +++ b/arch/powerpc/kernel/module_64.c
> @@ -422,11 +422,16 @@ static inline int create_stub(const Elf64_Shdr *sechdrs,
>  			      const char *name)
>  {
>  	long reladdr;
> +	func_desc_t desc;
> +	int i;
>  
>  	if (is_mprofile_ftrace_call(name))
>  		return create_ftrace_stub(entry, addr, me);
>  
> -	memcpy(entry->jump, ppc64_stub_insns, sizeof(ppc64_stub_insns));
> +	for (i = 0; i < sizeof(ppc64_stub_insns) / sizeof(u32); i++) {
> +		patch_instruction(&entry->jump[i],
> +				  ppc_inst(ppc64_stub_insns[i]));
> +	}
>  
>  	/* Stub uses address relative to r2. */
>  	reladdr = (unsigned long)entry - my_r2(sechdrs, me);
> @@ -437,10 +442,19 @@ static inline int create_stub(const Elf64_Shdr *sechdrs,
>  	}
>  	pr_debug("Stub %p get data from reladdr %li\n", entry, reladdr);
>  
> -	entry->jump[0] |= PPC_HA(reladdr);
> -	entry->jump[1] |= PPC_LO(reladdr);
> -	entry->funcdata = func_desc(addr);
> -	entry->magic = STUB_MAGIC;
> +	patch_instruction(&entry->jump[0],
> +			  ppc_inst(entry->jump[0] | PPC_HA(reladdr)));
> +	patch_instruction(&entry->jump[1],
> +			  ppc_inst(entry->jump[1] | PPC_LO(reladdr)));
> +
> +	// func_desc_t is 8 bytes if ABIv2, else 16 bytes
> +	desc = func_desc(addr);
> +	for (i = 0; i < sizeof(func_desc_t) / sizeof(u32); i++) {
> +		patch_instruction(((u32 *)&entry->funcdata) + i,
> +				  ppc_inst(((u32 *)(&desc))[i]));
> +	}
> +
> +	patch_instruction(&entry->magic, ppc_inst(STUB_MAGIC));
>  
>  	return 1;
>  }
> @@ -496,7 +510,7 @@ static int restore_r2(const char *name, u32 *instruction, struct module *me)
>  		return 0;
>  	}
>  	/* ld r2,R2_STACK_OFFSET(r1) */
> -	*instruction = PPC_INST_LD_TOC;
> +	patch_instruction(instruction, ppc_inst(PPC_INST_LD_TOC));
>  	return 1;
>  }
>  
> @@ -636,9 +650,9 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
>  			}
>  
>  			/* Only replace bits 2 through 26 */
> -			*(uint32_t *)location
> -				= (*(uint32_t *)location & ~0x03fffffc)
> +			value = (*(uint32_t *)location & ~0x03fffffc)
>  				| (value & 0x03fffffc);
> +			patch_instruction((u32 *)location, ppc_inst(value));
>  			break;
>  
>  		case R_PPC64_REL64:
> 

[[ cc += livepatching list ]]

Hi Russell,

Thanks for writing a minimal fix for stable / backporting.  As I
mentioned on the github issue [1], this avoided the crashes I reported
here and over on kpatch github [2].  I wasn't sure if this is the final
version for stable, but feel free to add my:

Tested-by: Joe Lawrence <joe.lawrence@redhat.com>

[1] https://github.com/linuxppc/issues/issues/375
[2] https://github.com/dynup/kpatch/issues/1228

-- 
Joe


  reply	other threads:[~2021-12-07 14:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-23  8:15 [PATCH] powerpc/module_64: Fix livepatching for RO modules Russell Currey
2021-12-07 14:44 ` Joe Lawrence [this message]
2021-12-08  1:51   ` Russell Currey
2021-12-09  7:00     ` Michael Ellerman
2021-12-10  3:08       ` Joe Lawrence
2021-12-15  0:51 ` Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d9d9ef2d-4aaa-7d8b-d15e-0452a355c5cf@redhat.com \
    --to=joe.lawrence@redhat.com \
    --cc=jniethe5@gmail.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=live-patching@vger.kernel.org \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=ruscur@russell.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).