This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v12 00/32] Validate binary before use
- From: Doug Evans <xdje42 at gmail dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Mon, 14 Sep 2015 18:36:07 -0700
- Subject: Re: [PATCH v12 00/32] Validate binary before use
- Authentication-results: sourceware.org; auth=none
- References: <20150821212006 dot 6673 dot 35100 dot stgit at host1 dot jankratochvil dot net> <CADPb22SaGgC15w0C42TzYJK=02i0=jkPw6BJk3UrHSG1n-UZVQ at mail dot gmail dot com> <20150902074113 dot GA32556 at host1 dot jankratochvil dot net> <CAP9bCMSZ54sAXGcWUrEvu2Ei8LVimkfUJHMvNJxuaixna5U0iQ at mail dot gmail dot com> <20150902151404 dot GA12757 at host1 dot jankratochvil dot net> <CAP9bCMToN5taa2fOP4V17=4hL4cfusGhF9FnTnb3imqgys+LFA at mail dot gmail dot com> <20150902191249 dot GA17111 at host1 dot jankratochvil dot net>
Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> Hello Doug,
>
> this discussion is offtopic for this patchset and it touches areas I am not
> yet sure how I will change/rewrite before posting the linux-nat/corefile next
> part. OTOH that's also good as it can be at least designed ahead of coding.
Yeah.
[FAOD, I'm only seeking information at this point.
This particular subthread isn't part of a formal review of the patch.]
> On Wed, 02 Sep 2015 17:22:35 +0200, Doug Evans wrote:
>> On Wed, Sep 2, 2015 at 8:14 AM, Jan Kratochvil
>> <jan.kratochvil@redhat.com> wrote:
>> > The Fedora patchset intentionally disables build-ids verification/lookup if
>> > random-program is specified as it was breaking some compatibility
>>
>> Interesting. What kind of compatibility?
>
> I was looking up what it really was and there are two reasons:
>
> (1) I did not want to change behavior of Fedora fork of GDB against upstream.
> This is why I tried to keep the behavior of case
> "gdb random-program random-core"
> the same as upstream GDB has.
>
> This can be sure changed now when/if the feature gets upstreamed.
>
> (2) As discussed below for "Fedora native" loading of core-files fully
> according to build-ids any behavior is OK as such case does not work for
> upstream GDB at all. In such case the strict build-id matching is the
> best one for user IMO as shown in:
> non-matching build-id libraries should not be loaded for `gdb -c'
> https://bugzilla.redhat.com/show_bug.cgi?id=524572
> +
> Base the backtrace strictly on build-id
> https://bugzilla.redhat.com/show_bug.cgi?id=525721
Thanks.
I think upstream will definitely want the verification
if both program + core are provided.
[plus a way to turn the verification off!]
Set aside vendor-provided binaries.
Imagine Joe User has a binary and a core file.
Or imagine an entire community of programmers, binaries, and cores.
Making sure one is using the right core file with the right
program is important.
>> > and IMO it
>> > does not make sense to specify random-program if build-ids are available.
>>
>> Why is that?
>> [Just because one has a build id doesn't necessarily mean one knows where
>> a program is. Or did I misunderstand?]
>
> On Fedora for build-id -> filename mapping one needs the appropriate
> n-debuginfo-v-r.a.rpm installed. IMO on development machines they are
> installed most of the time because otherwise Fedora GDB all the time annoys
> users by complaints they should get installed. If it is missing for any reason
> one can easily get it installed as shown at the end of this mail. (OK, maybe
> it can be made even easier but that would require better integration with the
> ever-changing packaging front-ends on Fedora.)
>
> There were some discussions how the build-id -> filename mapping should be
> stored. Currently it is done by on-disk symlinks in /usr/lib/debug/.build-id/
> stored in *-debuginfo.rpm (therefore to get just the build-id -> filename
> mapping symlink even for an already installed binary one needs to install
> *-debuginfo.rpm).
> # ls -l /usr/lib/debug/.build-id/b3/e636b621bb16456d201edca942442bdbf045f9*
> lrwxrwxrwx 1 root root 21 Jul 16 10:42 /usr/lib/debug/.build-id/b3/e636b621bb16456d201edca942442bdbf045f9 -> ../../../../bin/sleep*
> lrwxrwxrwx 1 root root 25 Jul 16 10:42 /usr/lib/debug/.build-id/b3/e636b621bb16456d201edca942442bdbf045f9.debug -> ../../usr/bin/sleep.debug
> # rpm -qf /usr/lib/debug/.build-id/b3/e636b621bb16456d201edca942442bdbf045f9{,.debug} /bin/sleep /usr/lib/debug/usr/bin/sleep.debug
> coreutils-debuginfo-8.24-2.fc23.x86_64
> coreutils-debuginfo-8.24-2.fc23.x86_64
> coreutils-8.24-2.fc23.x86_64
> coreutils-debuginfo-8.24-2.fc23.x86_64
>
> Other possibilities would be to store build-ids into .rpm tags even in the main
> binary .rpms; but that would make dependency of the build-ids resolving on rpm.
> Another possibility is to include the build-id symlinks into the main binary
> packages; but those symlinks can take a lot of disk space even when no
> debugging is required. Or to have some global or per-package sqlite database
> etc.
>
>
> Jan
>
>
> $ gdb -q core.23526
> [New LWP 23526]
> Missing separate debuginfo for the main executable file
> Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/b3/e636b621bb16456d201edca942442bdbf045f9
> Core was generated by `sleep 1h'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x00007f2810648bf0 in ?? ()
> "/home/jkratoch/t/core.23526" is a core file.
> Please specify an executable to debug.
> (gdb) q
> # dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/b3/e636b621bb16456d201edca942442bdbf045f9
> [...]
> Installed:
> coreutils-debuginfo.x86_64 8.24-2.fc23
> $ gdb -q core.23526
> [New LWP 23526]
> Reading symbols from /usr/bin/sleep...Reading symbols from /usr/lib/debug/usr/bin/sleep.debug...done.
> done.
>
> warning: Ignoring non-absolute filename: <linux-vdso.so.1>
> Missing separate debuginfo for linux-vdso.so.1
> Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/2b/fef7432912bcc87752ef9e66b1ddb71d7485f5
> Core was generated by `sleep 1h'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x00007f2810648bf0 in __nanosleep_nocancel () from /lib64/libc.so.6
> Missing separate debuginfos, use: dnf debuginfo-install glibc-2.21.90-21.fc23.x86_64
> (gdb) q
> # dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/2b/fef7432912bcc87752ef9e66b1ddb71d7485f5
> Last metadata expiration check performed 0:03:45 ago on Wed Sep 2 20:53:07 2015.
> No package /usr/lib/debug/.build-id/2b/fef7432912bcc87752ef9e66b1ddb71d7485f5 available.
> Error: no package matched
> --- Because matching kernel.rpm running on host OS is not available in this guest OS.
> # dnf debuginfo-install glibc-2.21.90-21.fc23.x86_64
> [...]
> Installed:
> glibc-debuginfo.x86_64 2.22-2.fc23 glibc-debuginfo-common.x86_64 2.22-2.fc23 nss-softokn-debuginfo.x86_64 3.20.0-1.0.fc23
> $ gdb -q core.26016
> [New LWP 26016]
> Reading symbols from /usr/bin/sleep...Reading symbols from /usr/lib/debug/usr/bin/sleep.debug...done.
> done.
>
> warning: Ignoring non-absolute filename: <linux-vdso.so.1>
> Missing separate debuginfo for linux-vdso.so.1
> Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/2b/fef7432912bcc87752ef9e66b1ddb71d7485f5
> Core was generated by `sleep 1h'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x00007f3fd8bd6870 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84
> 84 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
> (gdb) bt
> #0 0x00007f3fd8bd6870 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84
> #1 0x000055f9f5bf829f in rpl_nanosleep (requested_delay=requested_delay@entry=0x7ffe1323cb80,
> remaining_delay=remaining_delay@entry=0x0) at lib/nanosleep.c:85
> #2 0x000055f9f5bf8100 in xnanosleep (seconds=<optimized out>) at lib/xnanosleep.c:51
> #3 0x000055f9f5bf5a1d in main (argc=<optimized out>, argv=<optimized out>) at src/sleep.c:145
> (gdb) q