linux-kernel - Re: [PATCH v1 7/10] 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] [day] [month] [year] [list]

Message-ID: <20100325084152.GB26371@linux.vnet.ibm.com>
Date:	Thu, 25 Mar 2010 14:11:52 +0530
From:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Mel Gorman <mel@....ul.ie>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Roland McGrath <roland@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Christoph Hellwig <hch@...radead.org>,
	Ulrich Drepper <drepper@...hat.com>,
	Tom Tromey <tromey@...hat.com>
Subject: Re: [PATCH v1 7/10] Uprobes Implementation

> 
> I'm not sure, currently all the tracing bits require root. One of the
> complications is that dynamic trace events (kprobes and uprobes) share a
> global namespace, so making that accessible to users might be
> interesting.
> 
> So one thing we can do to avoid some of the trap overhead is to
> de-couple the trace event creation from trace event enable (pretty much
> already so for existing implementations), so while you define a dynamic
> trace event as dso:sym, you provide ways to enable it globally and per
> task.
> 
> We'd basically need a global and per-task refcount on enable and make
> sure the breakpoint is installed properly for (global || task).

Yes, when we allow two or more probes to co-exist at a probepoint, we
will be able to do this.

> 
> That way a perf per-cpu event will do the global enable, and a perf
> per-task event will do the task enable.
> 

> 
> A double scribble will be an issue for the current generation of
> debuggers anyway, right?
> 

double scribble as in two apps writing to the same address? Uprobes
handles this by failing into insert probes at location where there is a
breakpoint already inserted. So if both apps were to use the uprobes
interface, then they could co-operate and co-exist. (This would need the
feature in uprobes to have multiple probes per probepoint which is
excluded in this RFC).

> But yes, I suppose if you want to use uprobes for debuggers then yes it
> makes sense to allow to put the task to sleep. One way would be to
> provide means for the handler to detect the context and simply always
> return -EFAULT from the trap context.
> 

Yes, thats certainly possible. However lets consider the case when we
allow multiple probes per probepoint and one handler faults (handler
detects it could be sleeping) while the other handler may or may not
fault (handler could be doing a copy_from_user). 
When the thread switches to task context and runs the first handler but
it has no state information about the second handler having run in the
interrupt context. So here we may be unable to decide if we should run
the second handler or not.

--
Thanks and Regards
Srikar
--
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/