Bug 20500 - dlopen of libpthread in static executable crashes
Summary: dlopen of libpthread in static executable crashes
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: nptl (show other bugs)
Version: 2.4
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-22 09:31 UTC by Andreas Schwab
Modified: 2017-06-01 07:05 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
patch to fix the bug (2.99 KB, patch)
2017-06-01 06:15 UTC, ma.jiang
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Schwab 2016-08-22 09:31:43 UTC
When libpthread is dynamically loaded into a static executable the reference to _rtld_global is resolved to the instance in the (just loaded) ld.so, but when the libpthread initializer is run nothing has initialized _rtld_global yet.  This causes __pthread_initialize_minimal to crash when calling GL(dl_error_catch_tsd).
Comment 1 Florian Weimer 2016-08-22 13:25:56 UTC
Is this something we want to support?

I'm asking because it prevents quite a few potential optimizations on statically-linked binaries once link against libdl because we would have to assume that they can turn multi-threaded even if the main executable does not link against libpthread.
Comment 2 Andreas Schwab 2016-08-22 13:48:11 UTC
As long as we support nss modules.
Comment 3 Florian Weimer 2016-08-22 13:53:18 UTC
In our current implementation, NSS modules should never link against libpthread because NSS modules have to minimize the set of libraries and symbols they pull in (see bug 16881).

(I'm not saying this isn't a bug, but I'm just trying to put it into perspective.)
Comment 4 Andreas Schwab 2016-08-22 14:03:46 UTC
libnss_sss uses mutex functions that aren't in libc.
Comment 5 ma.jiang 2017-06-01 06:02:31 UTC
Hi, all
  I think this bug is not just about nss, it's more serious. A shared library dlopened by static executables could depend on libpthread. The writer of this shared library did nothing wrong, neither did the user of the library(who dlopen the library in a static executable). But the final program just can not act as expected because of this bug. 
  Generally speaking, the dlopened shared libraries and the static executable should be isolated from each other. The main executable use dlsym to access the functions provided by the shared libraries. Glibc currently support this usage, so we should try to make things right.
  In fact, there have been dl-static.c which provided a standard way to initialize variables in the dynamic linker ld.so. Unfortunately, this file currently just initialize the dl_pagesize. More over, many main stream architectures(such as arm/x86) did not even implement this file. 
  To fix this bug , I have unified dl-static.c, and added some lines to initialize GL(dl_error_catch_tsd). See the attached patch for more details. Hope this local fix could go upstream.
Comment 6 ma.jiang 2017-06-01 06:15:25 UTC
Created attachment 10079 [details]
patch to fix the bug
Comment 7 Florian Weimer 2017-06-01 06:20:19 UTC
(In reply to ma.jiang from comment #6)
> Created attachment 10079 [details]
> patch to fix the bug

Patches should be sent to the mailing list.  Current master no longer has dl_error_catch_tsd, as part of the fix for bug 16628.

Do you have a test case?  Maybe this bug has been fixed as well?
Comment 8 ma.jiang 2017-06-01 06:57:29 UTC
(In reply to Florian Weimer from comment #7)
Hi,
Thanks for your quick reply. 

> Patches should be sent to the mailing list.  Current master no longer has
> dl_error_catch_tsd, as part of the fix for bug 16628.
> Do you have a test case?  Maybe this bug has been fixed as well?
Yes, you are right, After the fix in "https://sourceware.org/git/?p=glibc.git;a=commit;h=9e78f6f6e7134a5f299cc8de77370218f8019237" applied. This bug should be gone. Currently, I'm using glibc-2.24 and I just checked the dl-static.c in the trunk... Sorry for this miss.
  But, I think the main part of this patch(a unified dl-static.c) still should be applied. Anyway,We should initialize variables in ld.so when the main executable is static linked(and dlopen some shared libraries).
  Currently, I cannot post mail to the mailing list as there were some problems in our email system... I'll post the patch later after our email system get fixed.