From: Will Deacon <will.deacon@arm.com>
To: Jessica Yu <jeyu@kernel.org>
Cc: Torsten Duwe <duwe@lst.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Julien Thierry <julien.thierry@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Ingo Molnar <mingo@redhat.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Arnd Bergmann <arnd@arndb.de>,
AKASHI Takahiro <takahiro.akashi@linaro.org>,
Miroslav Benes <mbenes@suse.cz>, Petr Mladek <pmladek@suse.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, live-patching@vger.kernel.org
Subject: Re: [PATCH v2] arm64/module: use mod->klp_info section header information for livepatch modules
Date: Mon, 29 Oct 2018 15:28:34 +0000 [thread overview]
Message-ID: <20181029152834.GA16289@arm.com> (raw)
In-Reply-To: <20181026172500.g65bl2p7cvey3qsx@linux-8ccs>
Hi Jessica,
On Fri, Oct 26, 2018 at 07:25:01PM +0200, Jessica Yu wrote:
> The arm64 module loader keeps a pointer into info->sechdrs to keep track
> of section header information for .plt section(s). A pointer to the
> relevent section header (struct elf64_shdr) in info->sechdrs is stored
> in mod->arch.{init,core}.plt. This pointer may be accessed while
> applying relocations in apply_relocate_add() for example. And unlike
> normal modules, livepatch modules can call apply_relocate_add() after
> module load. But the info struct (and therefore info->sechdrs) gets
> freed at the end of load_module() and so mod->arch.{init,core}.plt
> becomes an invalid pointer after the module is done loading.
>
> Luckily, livepatch modules already keep a copy of Elf section header
> information in mod->klp_info. So make sure livepatch modules on arm64
> have access to the section headers in klp_info and set
> mod->arch.{init,core}.plt to the appropriate section header in
> mod->klp_info so that they can call apply_relocate_add() even after
> module load.
>
> Signed-off-by: Jessica Yu <jeyu@kernel.org>
> ---
>
> v2:
> - fix missing free_module_elf() in error path
> - move copy_module_elf() and module_finalize() out of post_relocation()
> to make error handling more clear
> - add braces to if-else block in arm64 module_frob_arch_sections()
>
> arch/arm64/include/asm/module.h | 1 +
> arch/arm64/kernel/module-plts.c | 17 ++++++++++++-----
> arch/arm64/kernel/module.c | 10 ++++++++++
> kernel/module.c | 29 +++++++++++++++--------------
> 4 files changed, 38 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm64/include/asm/module.h b/arch/arm64/include/asm/module.h
> index fef773c94e9d..ac9b97f9ae5e 100644
> --- a/arch/arm64/include/asm/module.h
> +++ b/arch/arm64/include/asm/module.h
> @@ -25,6 +25,7 @@ struct mod_plt_sec {
> struct elf64_shdr *plt;
> int plt_num_entries;
> int plt_max_entries;
> + int plt_shndx;
> };
Does this mean we can drop the plt pointer from this struct altogether, and
simply offset into the section headers when applying the relocations?
Cheers,
Will
next prev parent reply other threads:[~2018-10-29 15:28 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-01 14:09 [PATCH v3 0/4] arm64 live patching Torsten Duwe
2018-10-01 14:16 ` [PATCH v3 1/4] DYNAMIC_FTRACE configurable with and without REGS Torsten Duwe
2018-10-01 14:52 ` Ard Biesheuvel
2018-10-01 15:03 ` Torsten Duwe
2018-10-01 15:06 ` Ard Biesheuvel
2018-10-01 15:10 ` Torsten Duwe
2018-10-01 15:14 ` Steven Rostedt
2018-10-01 14:16 ` [PATCH v3 2/4] arm64: implement ftrace with regs Torsten Duwe
2018-10-01 15:57 ` Ard Biesheuvel
2018-10-02 10:02 ` Torsten Duwe
2018-10-02 10:39 ` Ard Biesheuvel
2018-10-02 11:27 ` Mark Rutland
2018-10-02 12:18 ` Torsten Duwe
2018-10-02 12:57 ` Mark Rutland
2018-10-01 14:16 ` [PATCH v3 3/4] arm64: implement live patching Torsten Duwe
2018-10-17 13:39 ` Miroslav Benes
2018-10-18 12:58 ` Jessica Yu
2018-10-19 11:59 ` Miroslav Benes
2018-10-19 12:18 ` Jessica Yu
2018-10-19 15:14 ` Miroslav Benes
2018-10-19 13:46 ` Torsten Duwe
2018-10-19 13:52 ` Ard Biesheuvel
2018-10-19 15:21 ` Miroslav Benes
2018-10-20 14:10 ` Ard Biesheuvel
2018-10-22 12:53 ` Miroslav Benes
2018-10-22 14:54 ` Torsten Duwe
2018-10-23 17:55 ` [PATCH] arm64/module: use mod->klp_info section header information Jessica Yu
2018-10-23 19:32 ` kbuild test robot
2018-10-24 11:57 ` Miroslav Benes
2018-10-25 8:08 ` Petr Mladek
2018-10-25 9:00 ` Miroslav Benes
2018-10-25 11:42 ` Jessica Yu
2018-10-26 17:25 ` [PATCH v2] arm64/module: use mod->klp_info section header information for livepatch modules Jessica Yu
2018-10-29 13:24 ` Miroslav Benes
2018-10-29 13:32 ` Jessica Yu
2018-10-29 15:28 ` Will Deacon [this message]
2018-10-30 13:19 ` Jessica Yu
2018-11-01 15:18 ` Miroslav Benes
2018-11-01 16:07 ` Will Deacon
2018-11-05 12:30 ` Ard Biesheuvel
2018-11-05 17:57 ` [PATCH] arm64/module: use plt section indices for relocations Jessica Yu
2018-11-05 18:04 ` Ard Biesheuvel
2018-11-05 18:53 ` [PATCH v2] " Jessica Yu
2018-11-05 18:56 ` Ard Biesheuvel
2018-11-05 19:26 ` Will Deacon
2018-11-05 19:49 ` Jessica Yu
2018-11-06 9:44 ` Miroslav Benes
2018-10-01 14:16 ` [PATCH v3 4/4] arm64: reliable stacktraces Torsten Duwe
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=20181029152834.GA16289@arm.com \
--to=will.deacon@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=duwe@lst.de \
--cc=jeyu@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=julien.thierry@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=mingo@redhat.com \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=takahiro.akashi@linaro.org \
/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).