Re: [PATCH v12 00/32] Validate binary before use

[Doug Evans <xdje42 at gmail dot com>]

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