linux-kernel - Re: Extending coredump note section to contain filenames

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: <4F5F39B9.1090109@redhat.com>
Date:	Tue, 13 Mar 2012 13:12:41 +0100
From:	Denys Vlasenko <dvlasenk@...hat.com>
To:	Jan Kratochvil <jan.kratochvil@...hat.com>
CC:	Roland McGrath <roland@...k.frob.com>,
	linux-kernel@...r.kernel.org, Oleg Nesterov <oleg@...hat.com>,
	Kushal Das <kdas@...hat.com>
Subject: Re: Extending coredump note section to contain filenames

On 03/12/2012 07:58 PM, Denys Vlasenko wrote:
> On 03/12/2012 05:53 PM, Jan Kratochvil wrote:
>> On Mon, 12 Mar 2012 13:05:56 +0100, Denys Vlasenko wrote:
>>> Why we don't save library names in coredump?
>>
>> Because they are useless.
>
> They may be useless in some situations. Not in every situation,
> by a long shot. Here is a live example from my system:
 >...

Another example. abrt project wants to do better duplicate detection
for coredumps, where duplicate is defined as "this crash is probably
caused by the same bug".

This needs to be done quickly. Downloading and installing debuginfos
are definitely out of the question.

Karel decided to do it by walking the stack and creating a simplified
backtrace of this form:

BUILD_ID OFFSET SYMBOL MODNAME

where
BUILD_ID: build id of the binary file the address is mapped to.
OFFSET: offset from the start of the executable section of the file
     the stored instruction pointer points to.
SYMBOL: name of the function if it is known.
MODNAME: name of the binary or library.

We wrote a small standalone tool which generates such trace.
The code we have now frequently generates something like this:

ec1fd70dbee0db36eff9527254d9d2bbfd260f13 0x34a7 close_stdout [exe]
ec1fd70dbee0db36eff9527254d9d2bbfd260f13 0x3dd8 close_stdout [exe]
ec1fd70dbee0db36eff9527254d9d2bbfd260f13 0x2093 - [exe]
ec1fd70dbee0db36eff9527254d9d2bbfd260f13 0x1659 - [exe]

Naturally, "[exe]" is there because we don't know executable names.
I have a new code which uses saved /proc/pid/maps and it generates:

ec1fd70dbee0db36eff9527254d9d2bbfd260f13 0x34a7 close_stdout /usr/bin/md5sum
ec1fd70dbee0db36eff9527254d9d2bbfd260f13 0x3dd8 close_stdout /usr/bin/md5sum
ec1fd70dbee0db36eff9527254d9d2bbfd260f13 0x2093 - /usr/bin/md5sum
ec1fd70dbee0db36eff9527254d9d2bbfd260f13 0x1659 - /usr/bin/md5sum

If anyone would want to use this tool on a large collection
of coredumps with the intent of fishing out similar crashes
(this is not a theoretical assumption, we *do* have people
who badly need this feature), they won't get nice names of binaries,
they'll get non-informative "[exe]" things - because /proc/pid/maps
info is not saved in coredump, and won't be available.
This will impair ability to perform crash similarity analysis.

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