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:	Mon, 25 Jan 2010 08:52:41 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Kyle Moffett <kyle@...fetthome.net>
cc:	tytso@....edu, "Frank Ch. Eigler" <fche@...hat.com>,
	Ingo Molnar <mingo@...e.hu>, Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Peter Zijlstra <peterz@...radead.org>,
	Fr??d??ric Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...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 Sun, 24 Jan 2010, Kyle Moffett wrote:
> 
> The point that's being missed is that there is a chicken-and-egg
> problem here.  The "chicken" is a replacement or extension to the
> debugger interface that would make it possible for me to do things
> like GDB a process while it's being strace'd or vice versa.  The "egg"
> is the "utrace" bits, an unstable but somewhat arch-generic ABI that
> abstracts out ptrace() to make it possible to stack both in-kernel and
> userspace debuggers/tracers/etc and have multiple simultaneous users.

Quite frankly, as far as I'm concerned, I'd be a whole lot more interested 
in utrace if it's _only_ stated (and implied) goal was to do exactly this.

The thing I object to is the whole "dessert topping _and_ floor wax" 
thing, with kernel interfaces for random other users.

If somebody extended ptrace in good ways, that's a totally different 
thing. But I think utrace has been over-designed, possibly as a result of 
others coming in and saying "hey, I'd like to use that too for xyz".

"Do one thing, and do it well". I'd not mind somebody improving ptrace 
(including extending its semantics - I do agree that the whole SIGSTOP 
thing makes it hard to have multiple debuggers).

That said, I also suspect that people should still look seriously at 
simply just improving ptrace. For example, I suspect that the biggest 
problem with ptrace is really just the signalling, and that creating a new 
extension for JUST THAT, and then having a model where you can choose - at 
PTRACE_ATTACH time - how to wait for events would be a good thing.

But as long as it is "I want to solve all problems", I'm not very 
impressed. 

Maybe somebody would be interested in trying to take the utrace 
improvements, and scaling down what they promise, and ignoring all input 
except for "I want to strace and gdb at the same time".

So stop the crazy "new kernel interfaces" crap. Stop the crazy "maybe we 
can use it for ftrace and generic user event tracing too". Stop the crazy.

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