From: Petr Mladek <pmladek@suse.com>
To: Jessica Yu <jeyu@redhat.com>
Cc: Miroslav Benes <mbenes@suse.cz>,
Rusty Russell <rusty@rustcorp.com.au>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Seth Jennings <sjenning@redhat.com>,
Jiri Kosina <jikos@kernel.org>, Vojtech Pavlik <vojtech@suse.com>,
linux-api@vger.kernel.org, live-patching@vger.kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: module: save load_info for livepatch modules
Date: Thu, 12 Nov 2015 11:24:04 +0100 [thread overview]
Message-ID: <20151112102404.GL4431@pathway.suse.cz> (raw)
In-Reply-To: <20151112053228.GD30025@packer-debian-8-amd64.digitalocean.com>
On Thu 2015-11-12 00:33:12, Jessica Yu wrote:
> +++ Miroslav Benes [11/11/15 15:17 +0100]:
> >On Mon, 9 Nov 2015, Jessica Yu wrote:
> >
> >>diff --git a/include/linux/module.h b/include/linux/module.h
> >>index 3a19c79..c8680b1 100644
> >>--- a/include/linux/module.h
> >>+++ b/include/linux/module.h
> >
> >[...]
> >
> >>+#ifdef CONFIG_LIVEPATCH
> >>+extern void klp_prepare_patch_module(struct module *mod,
> >>+ struct load_info *info);
> >>+extern int
> >>+apply_relocate_add(Elf64_Shdr *sechdrs, const char *strtab,
> >>+ unsigned int symindex, unsigned int relsec,
> >>+ struct module *me);
> >>+#endif
> >>+
> >> #else /* !CONFIG_MODULES... */
> >
> >apply_relocate_add() is already in include/linux/moduleloader.h (guarded
> >by CONFIG_MODULES_USE_ELF_RELA), so maybe we can just include that where
> >we need it. As for the klp_prepare_patch_module() wouldn't it be better to
> >have it in our livepatch.h and include that in kernel/module.c?
>
> Yeah, Petr pointed this out as well :-) I will just include
> moduleloader.h for the apply_relocate_add() declaration.
>
> It also looks like we have some disagreement over where to put
> klp_prepare_patch_module(), either in livepatch/core.c (and add the
> function declaration in livepatch.h, and have module.c include
> livepatch.h) or in kernel/module.c, keeping the
> klp_prepare_patch_module() declaration in module.h. Maybe Rusty can
> provide some input.
>
> >> /* Given an address, look for it in the exception tables. */
> >>diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> >>index 6e53441..087a8c7 100644
> >>--- a/kernel/livepatch/core.c
> >>+++ b/kernel/livepatch/core.c
> >>@@ -1001,6 +1001,23 @@ static struct notifier_block klp_module_nb = {
> >> .priority = INT_MIN+1, /* called late but before ftrace notifier */
> >> };
> >>
> >>+/*
> >>+ * Save necessary information from info in order to be able to
> >>+ * patch modules that might be loaded later
> >>+ */
> >>+void klp_prepare_patch_module(struct module *mod, struct load_info *info)
> >>+{
> >>+ Elf_Shdr *symsect;
> >>+
> >>+ symsect = info->sechdrs + info->index.sym;
> >>+ /* update sh_addr to point to symtab */
> >>+ symsect->sh_addr = (unsigned long)info->hdr + symsect->sh_offset;
> >>+
> >>+ mod->info = kzalloc(sizeof(*info), GFP_KERNEL);
> >>+ memcpy(mod->info, info, sizeof(*info));
> >>+
> >>+}
> >
> >What about arch-specific 'struct mod_arch_specific'? We need to preserve
> >it somewhere as well for s390x and other non-x86 architectures.
>
> Ah! Thank you for catching this, I overlooked this important detail.
> Yes, we do need to save the arch-specific struct. We would be in
> trouble for s390 relocs if we didn't. I am trying to think of a way to
> save this information for s390, since s390's module_finalize() frees
> mod->arch.syminfo, which we definitely need in order for the call to
> apply_relocate_add() to work. Maybe we can add an extra call right
> before module_finalize() that will do some livepatch-specific
> processing and copy this information (this would be in
> post_relocation() in kernel/module.c). Perhaps this patchset cannot be
> entirely free of arch-specific code after all :-( Still thinking.
I think about adding a flag somewhere, e.g. mod->preserve_relocs.
It might be set in simplify_symbols() when SHN_LIVEPATCH is found.
It might be checked when freeing the needed structures in both
the generic and arch-specific code.
> >>+#ifdef CONFIG_LIVEPATCH
> >>+ /*
> >>+ * Save sechdrs, indices, and other data from info
> >>+ * in order to patch to-be-loaded modules.
> >>+ * Do not call free_copy() for livepatch modules.
> >>+ */
> >>+ if (get_modinfo((struct load_info *)info, "livepatch"))
> >>+ klp_prepare_patch_module(mod, info);
> >>+ else
> >>+ free_copy(info);
> >>+#else
> >> /* Get rid of temporary copy. */
> >> free_copy(info);
> >>+#endif
> >
> >Maybe I am missing something but isn't it necessary to call vfree() on
> >info somewhere in the end?
>
> So free_copy() will call vfree(info->hdr), except in livepatch modules
> we want to keep all the elf section information stored there, so we
> avoid calling free_copy(), As for the info struct itself, if you look
> at the init_module and finit_module syscall definitions in
> kernel/module.c, you will see that info is actually a local function
> variable, simply passed in to the call to load_module(), and will be
> automatically deallocated when the syscall returns. :-) No need to
> explicitly free info.
We still have to free the copied or preserved structures when
the module is unloaded.
Thank you,
Petr
next prev parent reply other threads:[~2015-11-12 10:24 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-10 4:45 [RFC PATCH 0/5] Arch-independent livepatch Jessica Yu
2015-11-10 4:45 ` [RFC PATCH 1/5] elf: add livepatch-specific elf constants Jessica Yu
2015-11-11 13:58 ` Petr Mladek
2015-11-12 15:33 ` Josh Poimboeuf
2015-11-12 15:45 ` Josh Poimboeuf
2015-11-13 6:49 ` Jessica Yu
2015-11-10 4:45 ` [RFC PATCH 2/5] module: save load_info for livepatch modules Jessica Yu
2015-11-11 8:08 ` Minfei Huang
2015-11-11 14:17 ` Miroslav Benes
2015-11-12 5:33 ` Jessica Yu
2015-11-12 10:24 ` Petr Mladek [this message]
2015-11-12 13:22 ` Miroslav Benes
2015-11-12 15:03 ` Petr Mladek
2015-11-12 17:05 ` Josh Poimboeuf
2015-11-12 22:17 ` Jessica Yu
2015-11-13 12:24 ` Miroslav Benes
2015-11-13 12:46 ` Miroslav Benes
2015-11-14 0:36 ` Jessica Yu
2015-11-16 12:12 ` Miroslav Benes
2015-11-13 12:56 ` Miroslav Benes
2015-11-14 2:09 ` Jessica Yu
2015-11-16 12:21 ` Miroslav Benes
2015-11-13 0:25 ` Jessica Yu
2015-11-11 14:31 ` [RFC PATCH 2/5] " Petr Mladek
2015-11-12 4:44 ` Jessica Yu
2015-11-12 10:05 ` Petr Mladek
2015-11-12 14:19 ` Miroslav Benes
2015-11-13 6:35 ` Jessica Yu
2015-11-13 13:07 ` Miroslav Benes
2015-11-13 8:20 ` Jessica Yu
2015-11-12 17:14 ` [RFC PATCH 2/5] " Josh Poimboeuf
2015-11-12 17:21 ` Josh Poimboeuf
2015-11-10 4:45 ` [RFC PATCH 3/5] livepatch: reuse module loader code to write relocations Jessica Yu
2015-11-10 8:13 ` Jiri Slaby
2015-11-11 14:30 ` Miroslav Benes
2015-11-11 20:07 ` Jessica Yu
2015-11-12 15:27 ` Miroslav Benes
2015-11-12 17:40 ` Josh Poimboeuf
2015-11-12 20:22 ` Jessica Yu
2015-11-12 20:32 ` Josh Poimboeuf
2015-11-13 7:15 ` Jessica Yu
2015-11-13 13:51 ` Miroslav Benes
2015-11-12 19:14 ` Jessica Yu
2015-11-12 20:35 ` Jessica Yu
2015-11-11 15:22 ` [RFC PATCH 3/5] " Petr Mladek
2015-11-11 18:27 ` Jessica Yu
2015-11-12 9:16 ` Petr Mladek
2015-11-12 17:59 ` [RFC PATCH 3/5] " Josh Poimboeuf
2015-11-10 4:45 ` [RFC PATCH 4/5] samples: livepatch: init reloc list and mark as klp module Jessica Yu
2015-11-10 8:15 ` Jiri Slaby
2015-11-10 13:50 ` Josh Poimboeuf
2015-11-10 18:37 ` Jessica Yu
2015-11-11 15:42 ` [RFC PATCH 4/5] " Petr Mladek
2015-11-12 6:02 ` Jessica Yu
2015-11-12 10:44 ` Miroslav Benes
2015-11-10 4:45 ` [RFC PATCH 5/5] livepatch: x86: remove unused relocation code Jessica Yu
2015-11-11 15:48 ` Petr Mladek
2015-11-12 18:01 ` Josh Poimboeuf
2015-11-11 14:00 ` [RFC PATCH 0/5] Arch-independent livepatch Miroslav Benes
2015-11-11 16:28 ` Josh Poimboeuf
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=20151112102404.GL4431@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=jeyu@redhat.com \
--cc=jikos@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=rusty@rustcorp.com.au \
--cc=sjenning@redhat.com \
--cc=vojtech@suse.com \
--cc=x86@kernel.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
Powered by JetHome