linux-kernel - Re: linux-next: add utrace tree

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:	Tue, 26 Jan 2010 17:08:11 +0100
From:	Johannes Stezenbach <js@...21.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Renzo Davoli <renzo@...unibo.it>, Mark Wielaard <mjw@...hat.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Kyle Moffett <kyle@...fetthome.net>, tytso@....edu,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Peter Zijlstra <peterz@...radead.org>,
	Fr??d??ric Weisbecker <fweisbec@...il.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	"Frank Ch. Eigler" <fche@...hat.com>, linux-next@...r.kernel.org,
	"H. Peter Anvin" <hpa@...or.com>, utrace-devel@...hat.com,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: linux-next: add utrace tree

On Mon, Jan 25, 2010 at 04:07:21PM -0800, Linus Torvalds wrote:
> On Tue, 26 Jan 2010, Renzo Davoli wrote:
> > 
> > The solution is that everybody can code his/her optimized kernel/user 
> > interface for tracing in his/her kernel module, i.e. utrace.
> 
> I don't think people understand. That is simply not a "solution". That is 
> a PROBLEM. The thing you describe is an absolute disaster. Which is 
> exactly why I rant against it.
> 
> The last thing we want to have is "here, take this, and make your own 
> kernel module mess around it optimized for your particular crazy 
> scenario".
> 
> But every SINGLE post in this thread that has argued for utrace has argued 
> exactly this way. 

I haven't followed much of the utrace discussions, but my impression was
that utrace primarily is a cleanup effort, replacing "don't change it,
you might break it" code with a clean, well defined (and even documented)
implementation.  To make it easier for people not familiar
with the low-level architecture details to experiment with
debugging stuff.

Two points to consider:

1. If you'd merge utrace + ptrace-on-utrace, but never anything else
   which uses the utrace API, wouldn't it still be an improvement?

2. A well defined utrace API makes debugging code more hackable, thus more
   likely that someone might come up with a brilliant killer debug
   feature in the future. (This might sound lame, but there are already
   a few people doing crazy things with utrace while I'm not aware
   that people have done such experiments based on the current ptrace impl.)

BTW, the ptrace improvements discussed elsewhere in this thread
(like using an fd intead of signals/wait) are orthogonal
to utrace, no?  IMHO it's a seperate discussion.

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