linux-kernel - Re: Fixing perf top --user shortcoming was: Re: [GIT PULL 0/9] perf/core improvements and fixes

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, 26 Jan 2012 12:30:37 -0200
From:	Arnaldo Carvalho de Melo <acme@...radead.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org, David Ahern <dsahern@...il.com>,
	David Daney <david.daney@...ium.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Jan Beulich <jbeulich@...e.com>,
	Joerg Roedel <joerg.roedel@....com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Mike Galbraith <efault@....de>,
	Namhyung Kim <namhyung.kim@....com>,
	Paul Mackerras <paulus@...ba.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: Fixing perf top --user shortcoming was: Re: [GIT PULL 0/9]
 perf/core improvements and fixes

Em Thu, Jan 26, 2012 at 02:09:19PM +0100, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo <acme@...radead.org> wrote:
> > > So what does --uid do which perf record --pid 1234 wouldnt 
> > > already do? By all means --uid ought to be a fancy way of 
> > > doing a whole bunch of perf record --pid 1234 profiling 
> > > sessions, at once.

> > I stopped at the kernel, i.e. used what can be done with what 
> > is available from the kernel right now, the diagnosis was sent 
> > in private, but boils down to:

> > +++ b/kernel/events/core.c
> > @@ -2636,7 +2636,8 @@ find_lively_task_by_vpid(pid_t vpid)
> >  	/* Reuse ptrace permission checks for now. */
> >  	err = -EACCES;
> > -	if (!ptrace_may_access(task, PTRACE_MODE_READ))
> > +	if (perf_paranoid_tracepoint_raw() &&
> > +	    !ptrace_may_access(task, PTRACE_MODE_READ))
> >  		goto errout;
> >  	return task;

> > ptrace_may_access(task, PTRACE_MODE_READ) fails for some tasks 
> > owned by the user because, IIRC, in __ptrace_may_access:

> Which tasks are these, are they privileged in any sense?

IIRC one of them was a child of sshd, that runs as root and then changes
the child ownership to the user logging in.

I'll continue investigation but probably for now the first thing to do
is to just remove them from the thread_map when they return -EPERM.
 
> If yes and if most of the 'real' tasks a user have can be 
> profiled just fine then i think we should just skip the 
> privileged tasks and not abort the profiling session?

Yeah, that can be done, while debugging I'll emit a warning with the
resulting thread_map of "special tasks" to figure out what makes them
special.

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