linux-kernel - Re: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes

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:	Tue, 12 Jan 2010 17:15:54 -0500
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	Masami Hiramatsu <mhiramat@...hat.com>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	utrace-devel <utrace-devel@...hat.com>,
	Jim Keniston <jkenisto@...ibm.com>,
	Maneesh Soni <maneesh@...ibm.com>,
	Mark Wielaard <mjw@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes

Hi -

> > As you might expect, in systemtap we've had to figure out this area
> > some time ago.  We use another utrace consumer called "task finder" [...]
> 
> So, could you tell us how the task-finder works and is implemented?

The code may be found at runtime/task_finder* in the systemtap sources.
There is a simple interest-registration structure/API that identifies
processes / shared libraries of interest, and a set of callbacks to be
invoked when said processes/shared libraries are mapped or unmapped.

It is implemented in terms of utrace callbacks for process/thread
lifetime monitoring, and utrace syscall callbacks for tracking shared
library segments being mapped and unmapped.

http://sourceware.org/git/?p=systemtap.git;a=tree;f=runtime

> I think we'd better clarify what functions are required for uprobes
> and pmu, and I think we may be able to re-implement improved pmu on
> utrace.

I don't see any collision between pmu / perf / utrace, so nothing is
really "required" for them or simple usage of uprobes.  If you wish to
track dynamic process/shared-library lifetimes, then you need extra
code somewhere to respond to those changes.  Layering this dynamic
capability seems like the natural way to go, and is easily done with
utrace and/or tracepoints.

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