linux-kernel - Re: ptrace bugs and related problems

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: <20060731190018.GA13735@nevyn.them.org>
Date:	Mon, 31 Jul 2006 15:00:18 -0400
From:	Daniel Jacobowitz <dan@...ian.org>
To:	Albert Cahalan <acahalan@...il.com>
Cc:	torvalds@...l.org, alan@...rguk.ukuu.org.uk, ak@...e.de,
	mingo@...e.hu, arjan@...radead.org, akpm@...l.org,
	linux-kernel@...r.kernel.org, roland@...hat.com
Subject: Re: ptrace bugs and related problems

On Fri, Jul 28, 2006 at 06:28:34PM -0400, Albert Cahalan wrote:
> I was using the data to look up which task just got split away
> from the parent. Judging by Chuck Ebbert's email, I'm not the
> only person to expect the data to be valid.

So it seems!  It seems a reasonable addition if anyone wants to submit
it.

> >Or just present things as if the leader task did the execve, which is
> >effectively what happens, and what I thought would happen for ptrace
> >too.
> 
> That makes things even weirder. A successful execve done in one
> thread appears to be done by another (which might not be
> traced if the debugger was a bit odd), while a failing execve
> appears... where?

Not at all, unless you're doing syscall tracing, I don't think.  The
exec notification is after the mm is replaced.

> >The interface was never designed to handle unsharing.  I don't really
> >think it should be extended to; whoever needs this functionality should
> >design something cleaner for utrace.
> 
> I'm not sure utrace will be accepted. (many ptrace alternatives
> have been born and died over the years) Even if utrace does get
> accepted, initially we only get:
> 
> 1. a clean-up that provides hope for the future
> 2. a hopefully-compatible ptrace on top of utrace
> 3. some sort of demo interface
> 
> That alone won't replace ptrace.

That's why I suggested someone design a cleaner debugging interface to
be implemented on top of utrace - which is how it's supposed to be
used.  Like David, I am confident that this is the future direction of
Linux debugging.

> >> PTRACE_GETSIGINFO has 0x0605 as si_code when a process exits.
> >> This is not defined anywhere.
> >
> >It's garbage.  PTRACE_GETSIGINFO is only valid after the process stops
> >with a signal.
> 
> The process does indeed stop with a signal. It gets SIGTRAP
> as part of sending the ptrace event.

Sure, but you must know what I meant.  PTRACE_GETSIGINFO is only valid
when there is a real signal, i.e. generated by something other than
ptrace.  Which is true whenever wait reports a signal without any of
the special event bits set (except for the legacy SIGTRAP on execve).

-- 
Daniel Jacobowitz
CodeSourcery
-
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/