linux-kernel - Re: [PATCH 2/5] ftrace perf: Move exclude_kernel tracepoint check to init event

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:	Thu, 24 Mar 2016 13:25:44 +0100
From:	Jiri Olsa <jolsa@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Jiri Olsa <jolsa@...nel.org>, Steven Rostedt <rostedt@...dmis.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: [PATCH 2/5] ftrace perf: Move exclude_kernel tracepoint check to
 init event

On Thu, Mar 24, 2016 at 11:49:34AM +0100, Peter Zijlstra wrote:
> On Thu, Mar 24, 2016 at 10:56:48AM +0100, Jiri Olsa wrote:
> > On Wed, Mar 23, 2016 at 11:41:29AM +0100, Peter Zijlstra wrote:
> > > On Wed, Mar 16, 2016 at 03:34:30PM +0100, Jiri Olsa wrote:
> > > > We suppress events with attr::exclude_kernel set when
> > > > the event is generated, so following capture will
> > > > give no warning but won't produce any data:
> > > > 
> > > >   $ sudo perf record -e sched:sched_switch:u ls
> > > >   $ sudo /perf script | wc -l
> > > >   0
> > > > 
> > > > Checking the attr::exclude_(kernel|user) at the event
> > > > init time and failing right away for tracepoints from
> > > > uprobes/kprobes and native ones:
> > > > 
> > > >   $ sudo perf record -e sched:sched_switch:u ls
> > > >   Error:
> > > >   The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (sched:sched_switch).
> > > >   /bin/dmesg may provide additional information.
> > > >   No CONFIG_PERF_EVENTS=y kernel support configured?
> 
> > > Not sure about this one. The previous behaviour suggests
> > > exclude_{user,kernel} is implemented, while the new behaviour says these
> > > flags are not implemented, which is a functional regression.
> > 
> > well I would not expect 'sched:sched_switch:u' to work (be implemented)
> > 
> > and I thought it's better to trigger an error than silently 'produce' no data
> 
> We're not in the business of protecting people from themselves are we?
> And if you want to help them, do so in userspace.

yep, I planned to make user space patch
to make that error more user friendly

> 
> And its not like the [uk] flags are hard to implement here.

sched:sched_switch:u ?

jirka