All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Miroslav Benes <mbenes@suse.cz>
Cc: jikos@kernel.org, jpoimboe@redhat.com, joe.lawrence@redhat.com,
	nstange@suse.de, live-patching@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 1/3] livepatch: Clear relocation targets on a module removal
Date: Wed, 2 Oct 2019 15:22:52 +0200	[thread overview]
Message-ID: <20191002132252.wufgbd23sgqptyye@pathway.suse.cz> (raw)
In-Reply-To: <20190905124514.8944-2-mbenes@suse.cz>

On Thu 2019-09-05 14:45:12, Miroslav Benes wrote:
> We thus decided to reverse the relocation patching (clear all relocation
> targets on x86_64, or return back nops on powerpc). The solution is not
> universal and is too much arch-specific, but it may prove to be simpler
> in the end.
> 
> diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
> index a93b10c48000..e461d456e447 100644
> --- a/arch/powerpc/kernel/module_64.c
> +++ b/arch/powerpc/kernel/module_64.c
> @@ -741,6 +741,51 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
>  	return 0;
>  }
>  
> +#ifdef CONFIG_LIVEPATCH
> +void clear_relocate_add(Elf64_Shdr *sechdrs,
> +		       const char *strtab,
> +		       unsigned int symindex,
> +		       unsigned int relsec,
> +		       struct module *me)
> +{
> +	unsigned int i;
> +	Elf64_Rela *rela = (void *)sechdrs[relsec].sh_addr;
> +	Elf64_Sym *sym;
> +	unsigned long *location;
> +	const char *symname;
> +	u32 *instruction;
> +
> +	pr_debug("Applying ADD relocate section %u to %u\n", relsec,

s/Applying/Clearing/

> +	       sechdrs[relsec].sh_info);
> +
> +	for (i = 0; i < sechdrs[relsec].sh_size / sizeof(*rela); i++) {
> +		location = (void *)sechdrs[sechdrs[relsec].sh_info].sh_addr
> +			+ rela[i].r_offset;
> +		sym = (Elf64_Sym *)sechdrs[symindex].sh_addr
> +			+ ELF64_R_SYM(rela[i].r_info);
> +		symname = me->core_kallsyms.strtab
> +			+ sym->st_name;
> +
> +		if (ELF64_R_TYPE(rela[i].r_info) != R_PPC_REL24)
> +			continue;

I expected that the code below would reverse the operations
in apply_relocate_add() for case R_PPC_REL24. But it is not
obvious for me.

It might be because I am not familiar with the code. Or would
it deserve some comments?

> +
> +		if (sym->st_shndx != SHN_UNDEF &&
> +		    sym->st_shndx != SHN_LIVEPATCH)
> +			continue;
> +
> +		instruction = (u32 *)location;
> +		if (is_mprofile_mcount_callsite(symname, instruction))
> +			continue;
> +
> +		if (!instr_is_relative_link_branch(*instruction))
> +			continue;
> +
> +		instruction += 1;
> +		*instruction = PPC_INST_NOP;
> +	}
> +}
> +#endif
> +
>  #ifdef CONFIG_DYNAMIC_FTRACE
>  
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index ab4a4606d19b..f0b380d2a17a 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -295,6 +295,45 @@ static int klp_write_object_relocations(struct module *pmod,
>  	return ret;
>  }
>  
> +static void klp_clear_object_relocations(struct module *pmod,
> +					struct klp_object *obj)
> +{
> +	int i, cnt;
> +	const char *objname, *secname;
> +	char sec_objname[MODULE_NAME_LEN];
> +	Elf_Shdr *sec;
> +
> +	objname = klp_is_module(obj) ? obj->name : "vmlinux";
> +
> +	/* For each klp relocation section */
> +	for (i = 1; i < pmod->klp_info->hdr.e_shnum; i++) {
> +		sec = pmod->klp_info->sechdrs + i;
> +		secname = pmod->klp_info->secstrings + sec->sh_name;
> +		if (!(sec->sh_flags & SHF_RELA_LIVEPATCH))
> +			continue;
> +
> +		/*
> +		 * Format: .klp.rela.sec_objname.section_name
> +		 * See comment in klp_resolve_symbols() for an explanation
> +		 * of the selected field width value.
> +		 */
> +		secname = pmod->klp_info->secstrings + sec->sh_name;
> +		cnt = sscanf(secname, ".klp.rela.%55[^.]", sec_objname);
> +		if (cnt != 1) {
> +			pr_err("section %s has an incorrectly formatted name\n",
> +			       secname);
> +			continue;
> +		}
> +
> +		if (strcmp(objname, sec_objname))
> +			continue;
> +

It would make the review easier when the order of 1st and 2nd
patch was swaped. I mean that I would not need to check twice
that the two functions actually share the same code.

> +		clear_relocate_add(pmod->klp_info->sechdrs,
> +				   pmod->core_kallsyms.strtab,
> +				   pmod->klp_info->symndx, i, pmod);
> +	}
> +}
> +
>  /*
>   * Sysfs Interface
>   *

I was not able to check correctness of the ppc and s390 parts.
Otherwise, it looks good to me.

Best Regards,
Petr

  reply	other threads:[~2019-10-02 13:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-05 12:45 [RFC PATCH v2 0/3] livepatch: Clear relocation targets on a module removal Miroslav Benes
2019-09-05 12:45 ` [RFC PATCH v2 1/3] " Miroslav Benes
2019-10-02 13:22   ` Petr Mladek [this message]
2019-10-03  8:55     ` Miroslav Benes
2019-10-02 18:18   ` Josh Poimboeuf
2019-10-03  9:17     ` Miroslav Benes
2019-09-05 12:45 ` [RFC PATCH v2 2/3] livepatch: Unify functions for writing and clearing object relocations Miroslav Benes
2019-10-02 13:35   ` Petr Mladek
2019-09-05 12:45 ` [RFC PATCH v2 3/3] livepatch: Clean up klp_update_object_relocations() return paths Miroslav Benes
2019-10-02 13:46   ` Petr Mladek
2019-10-03  9:08     ` Miroslav Benes
2019-10-01 12:30 ` [RFC PATCH v2 0/3] livepatch: Clear relocation targets on a module removal Miroslav Benes

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=20191002132252.wufgbd23sgqptyye@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=nstange@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.