linux-kernel - Re: perf test BPF failing on f24: fix

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]

Date:	Fri, 5 Aug 2016 18:45:50 +0900
From:	Masami Hiramatsu <mhiramat@...nel.org>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:	Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	"Wangnan (F)" <wangnan0@...wei.com>,
	Alexei Starovoitov <alexei.starovoitov@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: perf test BPF failing on f24: fix

On Thu, 4 Aug 2016 18:47:24 -0300
Arnaldo Carvalho de Melo <acme@...nel.org> wrote:

> Em Thu, Aug 04, 2016 at 04:36:56PM -0300, Arnaldo Carvalho de Melo escreveu:
> > So:
> > 
> > int err = debuginfo__get_text_offset(dbg, &baseaddr);
> > 
> > is returning 0, no relocation, its dwarf_addrdie() that is not finding
> > SyS_epoll_wait from its address.
> > 
> > Trying to figure out why dwarf_addrdie(0xffffffffbd295b50) fails...
> 
> So, trying to use that vmlinux with objdump to do disassembly I found
> that I need to do some offsetting, and after calculating it, this made
> things works for me:
> 
> diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
> index f2d9ff064e2d..9b95754f28ed 100644
> --- a/tools/perf/util/probe-finder.c
> +++ b/tools/perf/util/probe-finder.c
> @@ -1486,6 +1486,8 @@ retry:
>  	/* Find cu die */
>  	if (!dwarf_addrdie(dbg->dbg, (Dwarf_Addr)addr, &cudie)) {
>  		if (!reloc && debuginfo__get_text_offset(dbg, &baseaddr) == 0) {
> +			if (baseaddr == 0)
> +				baseaddr = -0x3c000000;

Hmm, strange... what's this magic number ...?
Actually debuginfo__get_text_offset() is for kernel modules and it relocate the offset.
But I guess sys_epoll_wait is in the kernel.

>  			addr += baseaddr;
>  			reloc = true;
>  			goto retry;
> 
> ----------------
> 
> With it, which is not a proper fix, of course, we get:
> 
> [root@...et ~]# perf probe sys_epoll_wait
> Added new events:
>   probe:sys_epoll_wait (on sys_epoll_wait)
>   probe:sys_epoll_wait_1 (on sys_epoll_wait)
>   probe:sys_epoll_wait_2 (on sys_epoll_wait)
> 
> You can now use it in all perf tools, such as:
> 
> 	perf record -e probe:sys_epoll_wait_2 -aR sleep 1
> 
> [root@...et ~]# 
> 
> Which, using -v shows it "finding" the alias:
> 
> [root@...et ~]# perf probe -v sys_epoll_wait
> probe-definition(0): sys_epoll_wait 
> symbol:sys_epoll_wait file:(null) line:0 offset:0 return:0 lazy:(null)
> 0 arguments
> Looking at the vmlinux_path (8 entries long)
> Using /lib/modules/4.7.0+/build/vmlinux for symbols
> Open Debuginfo file: /lib/modules/4.7.0+/build/vmlinux
> Try to find probe point from debuginfo.
> Symbol sys_epoll_wait address found : ffffffffbd295b50
> Matched function: SyS_epoll_wait
> found inline addr: 0xffffffff81295ee7
> Probe point found: compat_SyS_epoll_pwait+151
> found inline addr: 0xffffffff81295cca
> Probe point found: SyS_epoll_pwait+138
> found inline addr: 0xffffffff81295b50
> Probe point found: SyS_epoll_wait+0

Mine shows
----
Using /usr/lib/debug/lib/modules/4.6.4-301.fc24.x86_64/vmlinux for symbols
Open Debuginfo file: /usr/lib/debug/lib/modules/4.6.4-301.fc24.x86_64/vmlinux
Try to find probe point from debuginfo.
Symbol sys_epoll_wait address found : ffffffff81292d60  <-(*)
Matched function: SyS_epoll_wait
found inline addr: 0xffffffff812930f3
Probe point found: compat_SyS_epoll_pwait+147
found inline addr: 0xffffffff81292ed6
Probe point found: SyS_epoll_pwait+134
found inline addr: 0xffffffff81292d60
Probe point found: SyS_epoll_wait+0
Found 3 probe_trace_events.
-----

See the symbol address calcurated from symbol map, in successful case
the address exactly same address of SyS_epoll_wait. This indicates
something might wrong in the symbol map. (maybe KASLR?)
Could you check what happen if nokaslr is passed to your kernel?

Thank you,

> Found 3 probe_trace_events.
> Opening /sys/kernel/debug/tracing//kprobe_events write=1
> Writing event: p:probe/sys_epoll_wait _text+2711271
> Writing event: p:probe/sys_epoll_wait_1 _text+2710730
> Writing event: p:probe/sys_epoll_wait_2 _text+2710352
> Added new events:
>   probe:sys_epoll_wait (on sys_epoll_wait)
>   probe:sys_epoll_wait_1 (on sys_epoll_wait)
>   probe:sys_epoll_wait_2 (on sys_epoll_wait)
> 
> You can now use it in all perf tools, such as:
> 
> 	perf record -e probe:sys_epoll_wait_2 -aR sleep 1
> 
> [root@...et ~]# 
> 
> ----------
> 
> Now to figure out why baseaddr is returning as zero...
> 
> - Arnaldo


-- 
Masami Hiramatsu <mhiramat@...nel.org>