linux-kernel - Re: [PATCH 5/5][RFC] kprobes: Use ftrace hooks when probing ftrace nops

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: <1313154857.18583.320.camel@gandalf.stny.rr.com>
Date:	Fri, 12 Aug 2011 09:14:17 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	ananth@...ibm.com
Cc:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Jason Baron <jbaron@...hat.com>, yrl.pp-manager.tt@...achi.com
Subject: Re: [PATCH 5/5][RFC] kprobes: Use ftrace hooks when probing ftrace
 nops

On Fri, 2011-08-12 at 11:16 +0530, Ananth N Mavinakayanahalli wrote:
> On Thu, Aug 11, 2011 at 09:22:36AM -0400, Steven Rostedt wrote:
> > On Thu, 2011-08-11 at 16:41 +0900, Masami Hiramatsu wrote:
> 
> ...
> 
> > > > +#ifdef CONFIG_FUNCTION_TRACER
> > > > +static notrace void
> > > > +kprobe_ftrace_callback(unsigned long ip, unsigned long parent_ip,
> > > > +		       struct ftrace_ops *op, struct pt_regs *pt_regs)
> > > > +{
> > > > +	struct kprobe *p = container_of(op, struct kprobe, fops);
> > > > +
> > > 
> > > Here, we need to set up kprobe_ctlblk and some of pt_regs members,
> > > ip, cs and orig_ax as optimized_callback()@arch/x86/kernel/kprobes.c
> > > does.
> > 
> > I'm curious to what this is used for? It doesn't seem to be needed for
> > the generic kprobes. Because we know the probe was on a nop, there's no
> > need to simulate the operation. IOW, there's no need for singlestep() or
> > other gdb like operations.
> 
> It is needed to handle recursion, for instance. If in the rare case a
> kprobe handler calls another routine which also has a kprobe installed
> (and so on), we just bypass calling the 2nd kprobe's handlers. To do
> this and to set back the original kprobe context, we track the kprobe
> state in the per_cpu kprobe_ctlblk.

OK, so this looks a bit more involved. I'll look into this as well. This
is still all under RFC now anyway. But I think it is doable.

Thanks!

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/