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]

Message-ID: <20160324104934.GQ6356@twins.programming.kicks-ass.net>
Date:	Thu, 24 Mar 2016 11:49:34 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Jiri Olsa <jolsa@...hat.com>
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 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.

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