linux-kernel - Re: [RFC PATCH -tip 0/9]ftrace, kprobes: Ftrace-based kprobe optimization

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:	Fri, 01 Jun 2012 10:20:27 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	yrl.pp-manager.tt@...achi.com
Subject: Re: [RFC PATCH -tip  0/9]ftrace, kprobes: Ftrace-based kprobe
 optimization

On Fri, 2012-06-01 at 22:36 +0900, Masami Hiramatsu wrote:

> OK, so I've introduced new noprobe tag and replaced __kprobes
> with it. And now __kprobes tag which is a combination of noprobe
> and notrace, means that the function is not probed and it can be
> called from kprobe handler. (thus user must use this with their
> handlers and functions which will be used from the handlers)
> And also most of __kprobes tags are replaced by noprobe only.

You still haven't answered my question. Why can't function tracer still
trace these? If kprobes does not allow it to be probed, it should not
interfere with your code. But normal function tracing should still allow
these.

I still do not understand why you need to add 'notrace' at all.

> This means that you can trace those by function tracer :)
> 
> BTW, currently kprobes allows user cases pagefault in their
> handler (kprobe.fault_handler will handle it). I guess that
> can cause some problem with ftrace, isn't it? If so, I need
> to deny a kprobe using ftrace if it has fault_handler.

As long as there's recursion protection you are fine. In fact, I may add
recursion protection within the assembly itself, that will make all
function tracing safe. (does not solve the breakpoint bug from the other
thread, but will solve most other things). In fact, this may allow us to
remove notraces that were added because of recursion issues.

-- 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/