linux-kernel - Re: [RFC] [PATCH 4/7] Uprobes Implementation

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 16:53:48 -0800
From:	Jim Keniston <jkenisto@...ibm.com>
To:	ananth@...ibm.com
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Peter Zijlstra <peterz@...radead.org>,
	utrace-devel <utrace-devel@...hat.com>,
	Mark Wielaard <mjw@...hat.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Maneesh Soni <maneesh@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] [PATCH 4/7] Uprobes Implementation

On Tue, 2010-01-12 at 13:44 +0530, Ananth N Mavinakayanahalli wrote:
> On Tue, Jan 12, 2010 at 06:36:00AM +0100, Frederic Weisbecker wrote:
...
> > So, as stated before, uprobe seems to handle too much standalone
> > policies such as freeing on exec, always inherit on clone and never
> > on fork. Such rules should be decided from uprobe clients not
> > from uprobe itself and that makes it not enough flexible to
> > be usable for now.
> 
> The freeing on exec is only housekeeping of uprobe data structures. And
> probepoints are inherited only on CLONE_THREAD and not otherwise, simply
> since the existing probes can be hit in the new thread's context. Not
> sure what other policy you are hinting at.
> 
...
> > 
> > 
> > Typically, to use it with perf toward a pmu, perf tools need to
> > create a uprobe on perf process and activate its hook on the next exec.
> > Thereafter, it's up to perf to decide if we inherit through clone
> > and fork.
> 
> As mentioned above, the inheritance is only for threads. It should be
> fairly easy to inherit probes on fork, and that can be made a perf based
> policy decision.
> 

One reason we don't currently support inheritance (or cloning) of
uprobes across fork is that a uprobe object is (a) per-process (and I
think we want to keep it that way); and (b) owned by the uprobes client.
That is, the client creates and populates that uprobe object, and passes
a pointer to it to both register_uprobe() and unregister_uprobe().  We
could clone this object on fork, but then how would the client refer to
the cloned uprobes in the new process -- e.g., to unregister them?

I guess each cloned uprobe could remember its "patriarch" uprobe -- its
ultimate ancestor, the one created by the client; and we could add an
"unregister_uprobe_clone" function that takes both the address of the
patriarch uprobe and the pid of the (clone) uprobe to be unregistered.

It has also been suggested that it might be more user-friendly to 
let the client discard (or reuse) the uprobe object as soon as
register_uprobe() returns.  register_uprobe() would presumably copy 
everything it needs from the uprobe to the uprobe_kimg, and pass back 
a handle (e.g., the address of the uprobe_kimg) that the client can
later pass to unregister_uprobe() -- or unregister_uprobe_clone().  (In
this case, only the uprobe_kimg would be cloned.)  It might be good to
consider both these enhancement requests together.

Anyway, as previously described, the clone-on-fork feature can be (and
has been) implemented by a utrace-based task-finder that notices forks,
and creates and registers a whole new set of uprobes for the new
process.

Jim

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