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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51D51B88.5000406@hitachi.com>
Date:	Thu, 04 Jul 2013 15:51:52 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Namhyung Kim <namhyung@...nel.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Hyeoncheol Lee <cheol.lee@....com>,
	LKML <linux-kernel@...r.kernel.org>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: [PATCHSET 00/12] tracing/uprobes: Add support for more fetch
 methods

(2013/07/03 21:35), Namhyung Kim wrote:
> Hello,
> 
> This patchset implements memory (address), stack[N], deference,
> bitfield and retval (it needs uretprobe tho) fetch methods for
> uprobes.  It's based on the previous work [1] done by Hyeoncheol Lee.
> 
> Now kprobes and uprobes have their own fetch_type_tables and, in turn,
> memory and stack access methods.  Other fetch methods are shared.
> 
> For the dereference method, I added a new argument to fetch functions.
> It's because for uprobes it needs to know whether the given address is
> a file offset or a virtual address in an user process.  For instance,
> in case of fetching from a memory directly (like @offset) it should
> convert the address (offset) to a virtual address of the process, but
> if it's a dereferencing, the given address already has the virtual
> address.

Thanks Namhyung,
I agree that uprobe requires a special (file-relative) dereference
code. I'll look into the basic implementation after fixing current
dynamic-event related bugs. :)
(I see, this one should be updated to the latest tree, after
 merge window is closed)

Thank you,

> 
> To determine this in a fetch function, I passed a pointer to
> trace_uprobe for direct fetch, and passed NULL for dereference.
> 
> 
> [1] https://lkml.org/lkml/2012/11/14/84
> 
> Simple example:
> 
>   # cat foo.c
>   int glob = -1;
>   char str[] = "hello uprobe.";
> 
>   struct foo {
>     unsigned int unused: 2;
>     unsigned int foo: 20;
>     unsigned int bar: 10;
>   } foo = {
>     .foo = 5,
>   };
> 
>   int main(int argc, char *argv[])
>   {
>     long local = 0x1234;
> 
>     return 127;
>   }
> 
>   # gcc -o foo -g foo.c
> 
>   # objdump -d foo | grep -A9 -F '<main>'
>   00000000004004b0 <main>:
>     4004b0:	55                   	push   %rbp
>     4004b1:	48 89 e5             	mov    %rsp,%rbp
>     4004b4:	89 7d ec             	mov    %edi,-0x14(%rbp)
>     4004b7:	48 89 75 e0          	mov    %rsi,-0x20(%rbp)
>     4004bb:	48 c7 45 f8 34 12 00 	movq   $0x1234,-0x8(%rbp)
>     4004c2:	00 
>     4004c3:	b8 7f 00 00 00       	mov    $0x7f,%eax
>     4004c8:	5d                   	pop    %rbp
>     4004c9:	c3                   	retq   
> 
>   # nm foo | grep -e glob$ -e str -e foo
>   00000000006008bc D foo
>   00000000006008a8 D glob
>   00000000006008ac D str
> 
>   # perf probe -x /home/namhyung/tmp/foo -a 'foo=main+0x13 glob=@...a8:s32 \
>   > str=@...ac:string bit=@...bc:b10@...2 argc=%di local=-0x8(%bp)'
>   Added new event:
>     probe_foo:foo      (on 0x4c3 with glob=@...a8:s32 str=@...ac:string 
>                                  bit=@...bc:b10@...2 argc=%di local=-0x8(%bp))
> 
>   You can now use it in all perf tools, such as:
> 
>           perf record -e probe_foo:foo -aR sleep 1
> 
>   # perf record -e probe_foo:foo ./foo
>   [ perf record: Woken up 1 times to write data ]
>   [ perf record: Captured and wrote 0.001 MB perf.data (~33 samples) ]
> 
>   # perf script | grep -v ^#
>                foo  2008 [002  2199.867154: probe_foo:foo (4004c3)
>                    glob=4294967295 str="hello uprobe." bit=5 argc=1 local=1234
> 
> Note that 4294967295 is 0xffffffff.
> 
> Obviously, the perf tools also need to be improved.  I'll work on that
> later.
> 
> This patchset is based on the current tip/perf/core.  I also put this
> on my 'uprobe/fetch-v1' branch in my tree:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
> 
> 
> Any comments are welcome, thanks.
> Namhyung
> 
> 
> Cc: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
> Cc: Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
> Cc: Oleg Nesterov <oleg@...hat.com>
> Cc: Arnaldo Carvalho de Melo <acme@...stprotocols.net>
> 
> Hyeoncheol Lee (2):
>   tracing/kprobes: Move fetch functions to trace_kprobe.c
>   tracing/kprobes: Add fetch{,_size} member into symbol and deref fetch
>     method
> 
> Namhyung Kim (10):
>   tracing/kprobes: Make stack and memory fetch functions static
>   tracing/kprobes: Factor out struct trace_probe
>   tracing/uprobes: Convert to struct trace_probe
>   tracing/kprobes: Move common functions to trace_probe.c
>   tracing/kprobes: Remove duplicate set_print_fmt()
>   tracing/uprobes: Fetch args before reserving a ring buffer
>   tracing/uprobes: Fix a comment for uprobe registration syntax
>   tracing/kprobes: Add priv argument to fetch functions
>   tracing/uprobes: Add more fetch functions
>   tracing/uprobes: Add support for full argument access methods
> 
>  kernel/trace/trace_kprobe.c | 529 ++++++++++++++++++++++----------------------
>  kernel/trace/trace_probe.c  | 451 ++++++++++++++++++-------------------
>  kernel/trace/trace_probe.h  | 154 ++++++++++++-
>  kernel/trace/trace_uprobe.c | 429 ++++++++++++++++++++++++-----------
>  4 files changed, 926 insertions(+), 637 deletions(-)
> 


-- 
Masami HIRAMATSU
IT Management 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ