linux-kernel - Re: [RFD] Kprobes/Kretprobes perf support

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, 15 Aug 2009 16:33:17 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Masami Hiramatsu <mhiramat@...hat.com>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Jiaying Zhang <jiayingz@...gle.com>,
	Martin Bligh <mbligh@...gle.com>,
	Li Zefan <lizf@...fujitsu.com>, Jason Baron <jbaron@...hat.com>
Subject: Re: [RFD] Kprobes/Kretprobes perf support


* Masami Hiramatsu <mhiramat@...hat.com> wrote:

> Frederic Weisbecker wrote:
>> Ftrace events are supported by perfcounter currently but Kprobes
>> dynamic ftrace events are of a different nature: we must create them
>> before any toggling.
>>
>> So a large part is already done through the ftrace events and the fact
>> that you create one dynamically for each kprobes (we'll just need
>> a little callback for perf sample submission but that's a small
>> point).
>>
>> The largest work that remains is to port the current powerful interface
>> to create these k{ret}probes (with requested  arguments, etc...) through
>> ftrace but using perf open syscall.
>>
>> And I imagine it won't be trivial.
>>
>> Ingo, Peter do you have an idea on how we could do that?
>> We should be able to choose between a kprobe and kretprobe (these can
>> be two separate counters). And also one must be able to request the dump
>> of random desired parameters (or return values in case of kretprobe)
>> or registers...
>>
>> May be we should use the perf attr by passing a __user address to a buffer
>> that contains all these options?
>> Once we get that to the kernel, that can be passed to ftrace-kprobe that
>> can parse it, create the desired trace event and rely on perf to create
>> a counter for it.
>>
>> I guess that won't imply so much adds to Masami's patchset. Most of
>> the work is on the perf tools (parsing the user request).
>>
>> ./perf kprobes -e (func|addr):(c|r):(a1,a2,a3,... | rax,rbx,rcx,...)
>>                                ^  ^
>>                             c = call = kprobe
>>                             r = return = kretprobe
>
> If it is possible that libdwarf can be linked to the perf tool, I 
> think it might be better to support 'C source line/local variable' 
> style too, because basic dwarf decoding logic has already been 
> done in c2kpe which I posted yesterday :-).

Sure - we can link it - and C/source syntax beats everything else, 
hands down. We can also do the kind of automatic 'conditional 
linking' we do for C++ symbol demangling - i.e. if libdwarf is not 
installed we just emit a warning and dont build that functionality 
but otherwise perf will still be built fine.

Thus there will be no dependency on libdwarf.

One thing that occured to me is that it would be nice to have sanity 
checks of all sorts. For example we could expose the md5sum of the 
kernel image and perf would double check against that when looking 
around in the debuginfo - or something like that.

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