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]

Message-ID: <1263561930.4244.417.camel@laptop>
Date:	Fri, 15 Jan 2010 14:25:30 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	"Frank Ch. Eigler" <fche@...hat.com>
Cc:	Jim Keniston <jkenisto@...ibm.com>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Mark Wielaard <mjw@...hat.com>,
	utrace-devel <utrace-devel@...hat.com>
Subject: Re: [RFC] [PATCH 4/7] Uprobes Implementation

On Fri, 2010-01-15 at 08:10 -0500, Frank Ch. Eigler wrote:
> Hi -
> 
> > > > Then we can ditch the whole utrace muck as I see no reason to want to
> > > > use that, whereas the ubp (given a sane name) looks interesting.
> > > 
> > > Assuming you meant what you write, perhaps you misunderstand the
> > > layering relationship of these pieces.  utrace underlies uprobes and
> > > other process manipulation functionality, present and future.
> > 
> > Why, utrace doesn't at all look to bring a fundamental contribution to
> > all that. If there's a proper kernel interface to install probes on
> > userspace code (ubp seems to be mostly that) then I can use perf/ftrace
> > to do the rest of the state management, no need to use utrace there.
> 
> > You can hardly force me to use utrace there, can you?
> 
> utrace is not a form of punishment inflicted upon the undeserving.  It
> is a service layer that uprobes et alii are built upon.  You as a
> potential uprobes client need not also talk directly to it, if you
> wish to reimplement task-finder-like services some other way.

I said I wanted to, I think the whole task orientation of user-space
probing is wrong, its about text mappings.

But yes, I think that for most purposes utrace is a punishment, its way
too heavy, I mean, trap, generate a signal, catch the signal, that's
like an insane amount of code to jump through in order to get that trap.

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.

Yes you can do this with utrace, and I'm not going to stop people from
using utrace for his, I'm just saying I'm not going to.

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