linux-kernel - Re: [PATCH 0/5][RFC] kprobes/ftrace: Have kprobes use ftrace on 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]

Date:	Sat, 13 Aug 2011 19:09:48 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	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,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>
Subject: Re: [PATCH 0/5][RFC] kprobes/ftrace: Have kprobes use ftrace on ftrace
 nops

(2011/08/12 22:08), Steven Rostedt wrote:
> On Fri, 2011-08-12 at 11:57 +0900, Masami Hiramatsu wrote:
>
>> I don't think it won't work. It can work but on a long way.
>> Could you tell me your "bigger ideas"? Perhaps, we are on the different
>> way but aim to same goal.
>
> Part of the bigger ideas is to have things like function graph tracing
> use this, as it will simplify the entry.S code. There's other things
> that may come out of this too.

Hmm, I think that the current function graph tracing implementation
is more scalable than kretprobes, because kretprobe requires
spinlock on every hit. Moreover, you can't probe NMI handler with
kprobe, and kprobes on irq-handler are also possible to fail
because of recursive-call.
So I don't recommend using kretprobe for function-graph tracer :-(

However, even though, some parts of code can be shared among them
and it will simplify their implementations.

>>>> The cons:
>>>> - Native kprobes users will be disappointed... anyway, they just need to
>>>>   move their probes to the next instruction (usually addr+=5 is OK).
>>>
>>> I've been told that doing the addr+=5 (which is also arch specific) can
>>> break things for other tools.
>>
>> As I told in previous mail, I think kprobes can do that transparently.
>
> Yeah, it could, but I'm afraid this may need to be done differently for
> every arch. If I'm working on getting this code to work for ftrace,
> which will require modifying ever arch as well, kprobes can get the
> changes for free.

I guess that anyway it should be done (at least, carefully checked)
for every arch.

Thank you,


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com
--
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/