linux-kernel - Re: [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes (un)registration and exception handling.

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: <20100906182538.GA16735@Krystal>
Date:	Mon, 6 Sep 2010 14:25:38 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc:	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Christoph Hellwig <hch@...radead.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Mark Wielaard <mjw@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Naren A Devaiah <naren.devaiah@...ibm.com>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
Subject: Re: [PATCHv11 2.6.36-rc2-tip 5/15]  5: uprobes: Uprobes
	(un)registration and exception handling.

* Srikar Dronamraju (srikar@...ux.vnet.ibm.com) wrote:
> * Peter Zijlstra <peterz@...radead.org> [2010-09-03 19:19:09]:
> 
> > > 
> > > However I would have an issue with making inode based probing the
> > > default.
> > > 1. Making all probing based on inode can be a performance hog.
> > 
> > How so? You can add filters if you want.
> 
> The breakpoint exception and singlestep account for a substaintial time
> of the uprobes probe handling. With increasing number of breakpoint hits and
> singlesteps, wouldnt the overall load increase?
> 
> > 
> > > 2. Since unlike kernel space, every process has a different space, so
> > > why would we have to insert breakpoints in each of its process space if
> > > we are not interested in them.
> > 
> > You don't have to, but you can. The problem I have with this stuff is
> > that it makes the pid thing a primary interface, whereas it should be
> > one of many filter possibilities.
> 
> I think the otherway, 
> Why instrument a process and filter it out, if we are not interested in it.
> While instrumenting kernel, we dont have this flexibility. So
> having a pid based filter is the right thing to do for kernel
> based tracing.
> 
> If we can get the per process based tracing right, we can build
> higher lever stuff including the file based tracing easily.
> 
> All tools/debuggers in the past have all worked with process based
> tracing.
> 
> Tools like gdb can actually use the displaced singlestepping
> feature that uprobes provides. Some gdb developers have told on LKML
> earlier that they would be willing to use displaced singlestepping if
> the kernel provides an API that they can use.
> 
> Also about the security perspective when allowing normal users use
> perf to trace their applications. Using this model, we dont have to
> write extra filters to limit them. These filters might allow uprobe
> handlers on only tasks belonging to that user. However it still
> interrupts task of other users. And as I said earlier, breakpoint
> exception and singlestepping actually make a very very substantial part
> of the handling. The actual uprobe handler depending on what it does
> might actually be very minimal part of the uprobe probe handling.

I think we are both partially right in slightly different ways. I think Peter is
right in that the PID should not be mandatory (e.g. specifying a PID of 0 should
apply to all tasks), and you are also right in that being able to apply the
"filter" directly at the executable image level is vital for performance.

So how about this: we can provide both task and inode selection arguments. The
task selection argument can be 0 (apply to all tasks) or non-zero (one task
specifically). The inode argument would be mandatory.

Then, eventually, we can enhance the generic filtering facility so it can be
made aware of filtering shortcuts provided by the instrumentation (in this case,
uprobes would provide a per-tgid filtering shortcut).

Thoughts ?

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/