linux-kernel - Re: Trying to use 'perf probe' to debug perf itself

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]

Message-ID: <20150226144042.GB1079@kernel.org>
Date:	Thu, 26 Feb 2015 11:40:42 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jiri Olsa <jolsa@...hat.com>, David Ahern <dsahern@...il.com>
Subject: Re: Trying to use 'perf probe' to debug perf itself

Em Thu, Feb 26, 2015 at 01:57:42PM +0900, Masami Hiramatsu escreveu:
> (2015/02/25 22:25), Arnaldo Carvalho de Melo wrote:
> > Em Wed, Feb 25, 2015 at 11:53:16AM +0900, Masami Hiramatsu escreveu:
> >> (2015/02/25 3:49), Arnaldo Carvalho de Melo wrote:
> >> Hmm, strange. Could you tell me the version of your kernel?

> > [root@...andy ~]# uname -r
> > 3.10.0-210.el7.x86_64

> >> It seems that the kernel newer than 3.14 supports uprobes with
> >> memory dereference (e.g. -32(%sp) )feature.

> > Right, that must be the case, will test, but then, would it be possible
> > for the kernel, in such cases, return something line EOPNOTSUP?
 
> Yeah, but for now, it is already supported in kernel.
> Of cause we can try to test feature with adding temporary event
> from perftools too.

Yeah, capability querying is done in several places in tools/perf/
already, like when checking if we have perf_event_attr enabled features,
such as sample_id_all, etc.

Sometimes we can fallback to alternative mechanisms, sometimes we just
need to provide a less cryptic message.
 
> > I will try to figure out a better error message on the tooling side,
> > something like:

> > . Realize we're asking for memory dereference in uprobes
> > . If it fails with EINVAL, check the kernel version and say something
> >   like:
> > 
> > Please upgrade your kernel to at least x.y.z to have access to feature
> > FOO_BAR.
 
> OK, it may be worth for users (I'm not sure RHEL can update their kernel
> to include that enhancement)

That may be possible, will check with Jiri if we can include that in a
future backport.

Talking about these tools in conferences will make more people try the
things mentioned, and as we talk about the latest and greatest, we need
to try harder to handle error paths in a better way, providing less
cryptic messages.

Rebuilding a newer kernel now to retry all this, thanks!

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