linux-kernel - Re: [for-next][PATCH 12/16] kprobes: Initialize kprobes at postcore

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190703100205.0b58f3bf@gandalf.local.home>
Date:   Wed, 3 Jul 2019 10:02:05 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Mark Rutland <mark.rutland@....com>
Cc:     linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>
Subject: Re: [for-next][PATCH 12/16] kprobes: Initialize kprobes at
 postcore_initcall

On Tue, 2 Jul 2019 17:50:09 +0100
Mark Rutland <mark.rutland@....com> wrote:

> On Sun, May 26, 2019 at 03:18:40PM -0400, Steven Rostedt wrote:
> > From: Masami Hiramatsu <mhiramat@...nel.org>
> > 
> > Initialize kprobes at postcore_initcall level instead of module_init
> > since kprobes is not a module, and it depends on only subsystems
> > initialized in core_initcall.
> > This will allow ftrace kprobe event to add new events when it is
> > initializing because ftrace kprobe event is initialized at
> > later initcall level.
> > 
> > Link: http://lkml.kernel.org/r/155851394736.15728.13626739508905120098.stgit@devnote2
> > 
> > Signed-off-by: Masami Hiramatsu <mhiramat@...nel.org>
> > Signed-off-by: Steven Rostedt (VMware) <rostedt@...dmis.org>
> > ---
> >  kernel/kprobes.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > index b1ea30a5540e..54aaaad00a47 100644
> > --- a/kernel/kprobes.c
> > +++ b/kernel/kprobes.c
> > @@ -2289,6 +2289,7 @@ static int __init init_kprobes(void)
> >  		init_test_probes();
> >  	return err;
> >  }
> > +postcore_initcall(init_kprobes);  
> 
> As a heads-up, this is causing boot-time failures on arm64.

Thanks for the report.

> 
> On arm64 kprobes depends on the BRK handler we register in
> debug_traps_init(), which is an arch_initcall.
> 
> As of this change, init_krprobes() calls init_test_probes() before
> that's registered, so we end up hitting a BRK before we can handle it.
> 

Would something like this help?

-- Steve

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 5471efbeb937..0ca6f53c8505 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2235,6 +2235,8 @@ static struct notifier_block kprobe_module_nb = {
 extern unsigned long __start_kprobe_blacklist[];
 extern unsigned long __stop_kprobe_blacklist[];
 
+static bool run_kprobe_tests __initdata;
+
 static int __init init_kprobes(void)
 {
 	int i, err = 0;
@@ -2286,11 +2288,18 @@ static int __init init_kprobes(void)
 	kprobes_initialized = (err == 0);
 
 	if (!err)
-		init_test_probes();
+		run_kprobe_tests = true;
 	return err;
 }
 subsys_initcall(init_kprobes);
 
+static int __init run_init_test_probes(void)
+{
+	if (run_kprobe_tests)
+		init_test_probes();
+}
+module_init(run_init_test_probes);
+
 #ifdef CONFIG_DEBUG_FS
 static void report_probe(struct seq_file *pi, struct kprobe *p,
 		const char *sym, int offset, char *modname, struct kprobe *pp)