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: <20100115133825.GQ4822@redhat.com>
Date:	Fri, 15 Jan 2010 08:38:25 -0500
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
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

Hi -

On Fri, Jan 15, 2010 at 02:25:30PM +0100, Peter Zijlstra wrote:
> [...]
> > 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.
> 
> [...]
> 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.

At the bottom, there will be an int3 in the userspace text page.
There will be a trap taken, no matter what.  Code must figure out
whether this trap came from an in-kernel client such as uprobes, or
whether it is to be passed through to a userspace debugger via ptrace
(or the gdbstub).  This part is unavoidable if you wish to be
compatible.

I'm not sure, but it sounds like the part you're complaining about is
how utrace ultimately reports the trap to uprobes: i.e.,
utrace_get_signal()?  Is that the "insane amount of code"?

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

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