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]

Date:   Mon, 22 Jul 2019 13:34:37 +0100
From:   Catalin Marinas <catalin.marinas@....com>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Mark Rutland <mark.rutland@....com>,
        linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [for-next][PATCH 12/16] kprobes: Initialize kprobes at
 postcore_initcall

On Tue, Jul 09, 2019 at 09:30:49PM +0900, Masami Hiramatsu wrote:
> On Wed, 3 Jul 2019 10:02:05 -0400 Steven Rostedt <rostedt@...dmis.org>
> wrote:
> > 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:
> > > > 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);  
[...]
> > > 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.
[...]
> > 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);
> 
> Just out of curious, if arm64's handler code initialized in arch_initcall,
> why this subsys_initcall() function causes a problem?

It doesn't but patch 12/16 in this series changes it to
postcore_initcall().

-- 
Catalin