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: <4F5E4757.705@redhat.com>
Date:	Mon, 12 Mar 2012 19:58:31 +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 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:

$ ulimit -c unlimited
$ md5sum </dev/zero &
$ pid=$!
$ sleep 1
$ kill -ABRT $pid
$ gdb -ex "core core.12977"
GNU gdb (GDB) Fedora (7.3.50.20110722-10.fc16)
...
Missing separate debuginfo for the main executable file
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/ec/1fd70dbee0db36eff9527254d9d2bbfd260f13
[New LWP 12977]
Core was generated by `md5sum'.
Program terminated with signal 6, Aborted.
#0  0x0804b2b0 in ?? ()
(gdb) bt
#0  0x0804b2b0 in ?? ()
Backtrace stopped: Not enough registers or memory available to unwind further

      No backtrace at all.
      Let's tell it which binary was that:

(gdb) file /usr/bin/md5sum
Reading symbols from /usr/bin/md5sum...(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install coreutils-8.12-6.fc16.i686
(gdb) bt
#0  0x0804b2b0 in ?? ()
#1  0x0804bdd8 in ?? ()
#2  0x0804a093 in ?? ()
#3  0x08049659 in ?? ()
#4  0xb760f6b3 in ?? ()
Backtrace stopped: Not enough registers or memory available to unwind further

      This is better, isn't it?
      Wouldn't it be nice if gdb would retrieve binary's name by itself?
      (BTW: nothing prevents it from checking build ids and refusing
      to use it if they don't match.)

> If you have a filename there how to find which
> content it should match?  Even if you verify the file is still there with the
> same content there is a race it can no longer be true when you read the core
> file 5 seconds later.

And maybe root will run "rm -rf /*" in parallel. By this logic,
we should just give up on using computers.

> The build-id mapping server above always works and without races.

But it is not always available. Some people don't want to be connected
to internet; other can't be connected.

>>> it can have unknown content etc.
>>
>> I don't understand. *What* can have unknown content?
>
> You will save there "/lib64/libc-2.14.90.so".  But the next day you have no
> idea which compilation or build the core file was generated for, that virtual
> machine can be either already updated or even reinstalled from scratch etc.
> "/lib64/libc-2.14.90.so" does not say anything about the build.

Does it follow from the above that filenames are *never* useful?
I don't think so.

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