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:	Fri, 15 Jan 2010 15:11:25 -0800
From:	Jim Keniston <jkenisto@...ibm.com>
To:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Mark Wielaard <mjw@...hat.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	utrace-devel <utrace-devel@...hat.com>
Subject: Re: [RFC] [PATCH 4/7] Uprobes Implementation


On Fri, 2010-01-15 at 19:50 +0530, Srikar Dronamraju wrote:
> > 
> > > > Furthermore it requires stopping and resuming tasks and nonsense like
> > > > that, that's unwanted in many cases, just run stuff from the trap site
> > > > and you're done.
> > > 
> > > I don't know what you mean exactly.  A trap already stopped task.
> > > utrace merely allows various clients to inspect/manipulate the state
> > > of the task at that moment.  It does not add any context switches or
> > > spurious stop/resumue operations.
> > 
> > Srikar seemed to suggest it needed stop/resume.
> > 
> 
> If process traps, We dont need to stop/resume other threads.
> uprobes needs threads to quiesce when inserting/deleting the breakpoint.
> 

Years ago, we had pre-utrace versions of uprobes where the uprobes
breakpoint-handler code was dispatched from the die_notifier, before the
int3 turned into a SIGTRAP.  I believe that's what Peter is
recommending.  On my old Pentium M...
- a pre-utrace uprobe hit cost about 1 usec;
- a utrace-based uprobe hit cost about 3 usec;
- and an unboosted kprobe hit cost 0.57 usec.

So yeah, learning about the int3 via utrace after the SIGTRAP gets
created adds some overhead to uprobes.  But as previously discussed in
this thread -- e.g.,
http://lkml.indiana.edu/hypermail/linux/kernel/1001.1/02969.html --
there are ways to avoid the 2nd (single-step) trap, which should cut
overhead in half.

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/