From: Peter Zijlstra <peterz@infradead.org> To: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Petr Mladek <pmladek@suse.com>, x86@kernel.org, linux-kernel@vger.kernel.org, rostedt@goodmis.org, mhiramat@kernel.org, bristot@redhat.com, jbaron@akamai.com, torvalds@linux-foundation.org, tglx@linutronix.de, mingo@kernel.org, namit@vmware.com, hpa@zytor.com, luto@kernel.org, ard.biesheuvel@linaro.org, jeyu@kernel.org, live-patching@vger.kernel.org, Mark Rutland <mark.rutland@arm.com> Subject: Re: [PATCH v4 15/16] module: Move where we mark modules RO,X Date: Mon, 28 Oct 2019 11:07:21 +0100 Message-ID: <20191028100721.GK4131@hirez.programming.kicks-ass.net> (raw) In-Reply-To: <20191026011741.xywerjv62vdmz6sp@treble> On Fri, Oct 25, 2019 at 08:17:41PM -0500, Josh Poimboeuf wrote: > + * The following restrictions apply to module-specific relocation sections: > + * > + * a) References to vmlinux symbols are not allowed. Otherwise there might > + * be module init ordering issues, and crashes might occur in some of the > + * other kernel patching components like paravirt patching or jump > + * labels. All references to vmlinux symbols should use either normal > + * relas (for exported symbols) or vmlinux-specific klp relas (for > + * unexported symbols). This restriction is enforced in > + * klp_resolve_symbols(). Right. > + * b) Relocations to special sections like __jump_table and .altinstructions > + * aren't allowed. In other words, there should never be a > + * .klp.rela.{module}.__jump_table section. This will definitely cause > + * initialization ordering issues, as such special sections are processed > + * during the loading of the klp module itself, *not* the to-be-patched > + * module. This means that e.g., it's not currently possible to patch a > + * module function which uses a static key jump label, if you want to > + * have the replacement function also use the same static key. In this > + * case, a non-static interface like static_key_enabled() can be used in > + * the new function instead. Idem for .static_call_sites I suppose.. Is there any enforcement on this? I'm thinking it should be possible to detect the presence of these sections and yell a bit. OTOH, it should be possible to actually handle this, but let's do that later. > + * On the other hand, a .klp.rela.vmlinux.__jump_table section is fine, > + * as it can be resolved early enough during the load of the klp module, > + * as described above. > + */ > diff --git a/kernel/module.c b/kernel/module.c > index fe5bd382759c..ff4347385f05 100644 > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -2327,11 +2327,9 @@ static int apply_relocations(struct module *mod, const struct load_info *info) > if (!(info->sechdrs[infosec].sh_flags & SHF_ALLOC)) > continue; > > - /* Livepatch relocation sections are applied by livepatch */ > if (info->sechdrs[i].sh_flags & SHF_RELA_LIVEPATCH) > - continue; > - > - if (info->sechdrs[i].sh_type == SHT_REL) > + err = klp_write_relocations(mod, NULL); > + else if (info->sechdrs[i].sh_type == SHT_REL) > err = apply_relocate(info->sechdrs, info->strtab, > info->index.sym, i, mod); > else if (info->sechdrs[i].sh_type == SHT_RELA) Like here, we can yell and error if .klp.rela.{mod}.__jump_table sections are encountered. Other than that, this should work I suppose.
next prev parent reply index Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20191018073525.768931536@infradead.org> [not found] ` <20191018074634.801435443@infradead.org> [not found] ` <20191021135312.jbbxsuipxldocdjk@treble> [not found] ` <20191021141402.GI1817@hirez.programming.kicks-ass.net> [not found] ` <20191023114835.GT1817@hirez.programming.kicks-ass.net> 2019-10-23 17:00 ` Josh Poimboeuf 2019-10-24 13:16 ` Peter Zijlstra 2019-10-25 6:44 ` Petr Mladek 2019-10-25 8:43 ` Peter Zijlstra 2019-10-25 10:06 ` Peter Zijlstra 2019-10-25 13:50 ` Josh Poimboeuf 2019-10-26 1:17 ` Josh Poimboeuf 2019-10-28 10:07 ` Peter Zijlstra [this message] 2019-10-28 10:43 ` Peter Zijlstra 2019-10-25 9:16 ` Peter Zijlstra
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=20191028100721.GK4131@hirez.programming.kicks-ass.net \ --to=peterz@infradead.org \ --cc=ard.biesheuvel@linaro.org \ --cc=bristot@redhat.com \ --cc=hpa@zytor.com \ --cc=jbaron@akamai.com \ --cc=jeyu@kernel.org \ --cc=jpoimboe@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=live-patching@vger.kernel.org \ --cc=luto@kernel.org \ --cc=mark.rutland@arm.com \ --cc=mhiramat@kernel.org \ --cc=mingo@kernel.org \ --cc=namit@vmware.com \ --cc=pmladek@suse.com \ --cc=rostedt@goodmis.org \ --cc=tglx@linutronix.de \ --cc=torvalds@linux-foundation.org \ --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
Live-Patching Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/live-patching/0 live-patching/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 live-patching live-patching/ https://lore.kernel.org/live-patching \ live-patching@vger.kernel.org public-inbox-index live-patching Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.live-patching AGPL code for this site: git clone https://public-inbox.org/public-inbox.git