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 10:46:00 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andi Kleen <andi@...stfloor.org>
cc:	tromey@...hat.com, Stephen Rothwell <sfr@...b.auug.org.au>,
	Kyle Moffett <kyle@...fetthome.net>,
	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 Tue, 26 Jan 2010, Andi Kleen wrote:

> Tom Tromey <tromey@...hat.com> writes:
> 
> > * Use an fd, not SIGCHLD+wait, to report inferior state changes to gdb.
> >   Internally we're already using a self-pipe to integrate this into
> >   gdb's main loop.  Relatedly, don't mess with the inferior's parentage.
> 
> How would having a kernel based solution be better over your
> user space simulation?

Oh, the reason we should do something in the kernel is that you really 
can't do certain things with the ptrace() interface. 

For example, think about how Wine and UML use ptrace - and then realize 
that that makes it impossible to attach a debugger from the outside. 
That's a real deficiency in ptrace - much more so than the fact that there 
are some odd details (ie the whole "read/write a word at a time" is just a 
quirky detail in comparison - not a fundamental problem).

> BTW there's the new signalfd() system call that might do it
> (haven't checked if it works for SIGCHLD)

No, you miss the point.

The problem isn't that you want to turn signals into a file descriptor 
just because you like file descriptors.

The problem is that anything that is based on reparenting and signals is 
fundamentally a "one parent only" kind of interface. See?

So the reason I think using an fd is a good idea is _not_ because gdb 
already uses an fd internally, but because it gives you a "connection" 
between the debugger and debuggee that is not fundamentally limited to a 
single controller.

(It doesn't have to be a file descriptor, of course, but could be any kind 
of other model that allows multiple connections. It's just that in unix 
terms, using a file descriptor as the "cookie" for the connection is a 
very natural model. So the important part isn't the file descriptor 
itself, it's the model you could build).

			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/