linux-kernel - Re: Questions about ptrace on a dying process

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: <201203010812.54769.vda.linux@googlemail.com>
Date:	Thu, 1 Mar 2012 08:12:54 +0100
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Tim Bird <tim.bird@...sony.com>
Cc:	Andi Kleen <andi@...stfloor.org>, Oleg Nesterov <oleg@...hat.com>,
	linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: Questions about ptrace on a dying process

On Wednesday 29 February 2012 21:45, Tim Bird wrote:
> On 02/29/2012 11:12 AM, Andi Kleen wrote:
> > Tim Bird <tim.bird@...sony.com> writes:
> > 
> >> ptrace maintainers (and interested parties)...
> >>
> >> I'm working on a crash handler for Linux, which uses ptrace to retrieve information
> >> about a process during it's coredump.  Specifically, from within a core handler
> >> program (started within do_coredump() as a user_mode_helper), I would like to make
> >> ptrace calls against the dying process.
> > 
> > The standard approach is to define a core pipe handler and parse the
> > elf memory dump.
> 
> Yeah - I may be doing something new here.  Android uses ptrace
> in debuggerd, which is their crash reporting tool, but they wake
> it up with signals before the dying program goes into coredump.

I think ptrace API does not provide guarantees that it is possible
to attach to the process when it coredumps.

It might work in current kernels, but might break in new ones.

> I'm taking a different approach and trying to do initiated
> by the coredump feature in Linux.  This makes it so that
> a process does not need to be persistently running to capture
> these events.
> 
> This is on embedded systems, where the dump is not saved.  The dump
> is available via stdin to the core pipe handler, but it would be
> kind of a pain to wrapper that for random access, which is needed
> for stuff like stack unwinding.

Stack unwinding only requires the stack data and knowledge
of the mapped binary and library files. You can parse coredump's ELF header,
and skip all sizable data segments which you won't need anyway.

I estimate that usually you will need to save only ~150k of data
in order to produce a stacktrace, and even then,
only because Linux pre-allocates ridiculously large
stack for every new process - 132k. It can easily be reduced
to something saner with one-line patch.

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