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:	Sat, 23 Jan 2010 21:04:56 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Kyle Moffett <kyle@...fetthome.net>
cc:	"Frank Ch. Eigler" <fche@...hat.com>,
	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 Sat, 23 Jan 2010, Kyle Moffett wrote:
> 
> Now how do we get from here to a moderately portable API for
> interrogating, controlling, and intercepting process state?

Umm? ptrace?

It's not _pretty_, but it's a hell of a lot more portable than utrace is 
ever going to be. Yes, the details differ between OS's (and between 
architectures), but let's face it, things like register state probing is 
_never_ going to be portable across different architectures simply because 
the register state isn't the same.

> The killer app for this will be the ability to delete thousands of
> lines of code from GDB, strace, and all the various other tools that
> have to painfully work around the major interface gotchas of ptrace(),
> while at the same time making their handling of complex processes much
> more robust.

No. There is absolutely _no_ reason to believe that gdb et al would ever 
delete the ptrace interfaces anyway. 

That really is my point. Adding a new interface, when an old and crufty 
(but working) interface is inevitably going to be around anyway - and is 
inevitably always going to have portability issues - is STUPID.

Let's take strace, for example.

Yes, ptrace() is crufty, but have you actually looked at strace source 
code? The problem isn't really a crufty interface to read registers etc, 
the bigger problem for strace is that different architectures and OS's 
have different system call argument rules, different ways to read/write 
system call numbers yadda yadda yadda.

Take a look at strace sources some day. Moving away from ptrace on Linux 
(even if you decided that you don't care about old versions of the kernel 
that don't know anything else) would simplify ABSOLUTELY NOTHING.

Really. Quiet the reverse, I suspect. The Solaris and FreeBSD support uses 
ptrace too, afaik, so you' just be confusing the issue.

And the fact is, strace would still end up supporting ptrace anyway, just 
so that you could run it on old kernels.

So the whole "making a new utrace interface would simpligy things" is 
simply a total lie. The fact that ptrace is a bit of an odd interface IN 
NO WAY means that any other interface would end up being appreciably 
simpler.

It would just result in _more_ code in strace, and more confusion.

		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/