Opening a "debug" shared object leads to crash. If I split a shared object library using "objcopy --only-keep-debug", opening the produced library with dlopen raise a SIGSEGV. This happened with yocto/openembedded that separate debugging symbols and place it in separate .debug directory. The issue came when scanning for shared libraries recursively and opening found .so files (by example, yocto installs: ROOT/x.so and ROOT/.debug/x.so) then opening the debug shared object was made. Is there an easy way to know that a shared object is for debug symbols? I don't found one except that ldconfig says "statically linked" (or something like that, meaning that there is no dependency to any other library). But using dlopen is the prefered way, dlopen that should fail in that case but not SIGSEGV. links: https://jira.automotivelinux.org/browse/SPEC-662 https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
Separate debug objects violate the ELF spec in various ways, like having an invalid .dynamic section.
Does it means that dlopen is authorized to crash (SIGSEGV)? I don't share your opinion.
(In reply to José Bollo from comment #2) > Does it means that dlopen is authorized to crash (SIGSEGV)? > > I don't share your opinion. This is not an invalid bug, but a failure of the GNU toolchain to correctly mark "debug" shared objects. In fact I just spoke with Nick Clifton about this in binutils, and it requires we mark the "debug" shared objects to avoid this problem. There is lots of tooling which needs to be updated to avoid loading "debug" shared objects. I'm reopening this bug and retitling.
Right now we need a binutils enhancement to mark such objects, so I'm marking this bug WAITING for the binutils changes.
Try this: diff --git a/elf/dl-load.c b/elf/dl-load.c index a067760cc6..261ec997c8 100644 --- a/elf/dl-load.c +++ b/elf/dl-load.c @@ -1052,8 +1052,11 @@ _dl_map_object_from_fd (const char *name, const char *origname, int fd, segments are mapped in. We record the addresses it says verbatim, and later correct for the run-time load address. */ case PT_DYNAMIC: - l->l_ld = (void *) ph->p_vaddr; - l->l_ldnum = ph->p_memsz / sizeof (ElfW(Dyn)); + if (ph->p_filesz) + { + l->l_ld = (void *) ph->p_vaddr; + l->l_ldnum = ph->p_memsz / sizeof (ElfW(Dyn)); + } break; case PT_PHDR:
> Does it means that dlopen is authorized to crash (SIGSEGV)? Yes, because you allow it to run arbitrary code.
(In reply to José Bollo from comment #2) > Does it means that dlopen is authorized to crash (SIGSEGV)? > > I don't share your opinion. (In reply to Andreas Schwab from comment #6) > > Does it means that dlopen is authorized to crash (SIGSEGV)? > > Yes, because you allow it to run arbitrary code. As Andreas states, the answer is "Yes", but within reason. The context of the various ways in which we check errors or don't (and crash) is covered under the project "Style and Conventions" on error handling: https://sourceware.org/glibc/wiki/Style_and_Conventions#Error_Handling Having the loader check all possible errors would make it slow in the normal case, and the normal case is that ELF binaries are well formed. There is a double problem here: ldd is the loader itself running in trace mode, and that has problems. I have started an eu-ldd project that is robust against such failures and that would make ldd more robust in detecting debug info vs. real binaries, however this change would still be welcome in that case as a quick way to determine which files are what.
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, master has been updated via 592d5c75392e1da170050a4999af0618c4865aed (commit) from 2d9193f2f55767c71333d425e140e22c3e15dc3d (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=592d5c75392e1da170050a4999af0618c4865aed commit 592d5c75392e1da170050a4999af0618c4865aed Author: H.J. Lu <hjl.tools@gmail.com> Date: Tue Sep 26 13:49:48 2017 -0700 Skip PT_DYNAMIC segment with p_filesz == 0 [BZ #22101] ELF objects generated with "objcopy --only-keep-debug" have Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align DYNAMIC 0x0+e28 0x0+200e40 0x0+200e40 0x0+ 0x0+1a0 RW 0x8 with 0 file size. ld.so should skip such PT_DYNAMIC segments. Without a PT_DYNAMIC segment the loading of the shared object will fail, and therefore ldd on such objects will also fail instead of crashing. This provides better diagnostics for tooling that is attempting to inspect the invalid shared objects which may just contain debug information. [BZ #22101] * elf/Makefile (tests): Add tst-debug1. ($(objpfx)tst-debug1): New. ($(objpfx)tst-debug1.out): Likewise. ($(objpfx)tst-debug1mod1.so): Likewise. * elf/dl-load.c (_dl_map_object_from_fd): Skip PT_DYNAMIC segment with p_filesz == 0. * elf/tst-debug1.c: New file. Reviewed-by: Carlos O'Donell <carlos@redhat.com> ----------------------------------------------------------------------- Summary of changes: ChangeLog | 11 +++++++++++ elf/Makefile | 9 ++++++++- elf/dl-load.c | 10 ++++++++-- elf/{tst-audit11.c => tst-debug1.c} | 13 ++++++------- 4 files changed, 33 insertions(+), 10 deletions(-) copy elf/{tst-audit11.c => tst-debug1.c} (75%)
Fixed for 2.27.
(In reply to Andreas Schwab from comment #6) > > Does it means that dlopen is authorized to crash (SIGSEGV)? > > Yes, because you allow it to run arbitrary code. That is a problem in fact: how to dlopen a library to just inspect its content? There is no option to avoid calls to constructors/destructors and IMHO it's really missing. Obviously providing such option would imply features for explicitely call constructors, a reopen perhaps. Thank for resolution of the error.
(In reply to José Bollo from comment #10) > (In reply to Andreas Schwab from comment #6) > > > Does it means that dlopen is authorized to crash (SIGSEGV)? > > > > Yes, because you allow it to run arbitrary code. > > That is a problem in fact: how to dlopen a library to just inspect its > content? There is no option to avoid calls to constructors/destructors and > IMHO it's really missing. You can use libelf from elfutils for that, or BFD from binutils.