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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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.


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


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