10 Sep
2015
10 Sep
'15
12:53 p.m.
Hi,
I'm experiencing problems with uClibc-ng when creating static binaries
that uses threads. I originally reported this to the buildroot mailing
list but got redirected here instead.
The problem is when using a combination of stack protection, threads and
static binaries. The program will during start up get a sigsegv in
__pthread_initialize_minimal_internal(), and gdb says the instruction is
a
mov %fs:0x28,%rax
where %fs is 0x00. The reason for that is that the pthread library is
compiled with stack protection but __pthread_initialize_minimal_internal
is called before __libc_setup_tls in static binaries.
I have created an ugly patch to verify my hypothesis (attached). With
that patch the test program works, but what is the proper way to solve
this issue?
With uClibc 0.9.33.x the same thing happens. With glibc the program
works.
Best regards,
Daniel Fahlgren
14 Sep
14 Sep
4:52 a.m.
New subject: problem with stack protection, threads and static binaries
Hi Daniel,
Daniel Fahlgren wrote,
Hi,
I'm experiencing problems with uClibc-ng when creating static binaries
that uses threads. I originally reported this to the buildroot mailing
list but got redirected here instead.
I have seen your comprehensive bug report.
The problem is when using a combination of stack
protection, threads and
static binaries. The program will during start up get a sigsegv in
__pthread_initialize_minimal_internal(), and gdb says the instruction is
a
mov %fs:0x28,%rax
where %fs is 0x00. The reason for that is that the pthread library is
compiled with stack protection but __pthread_initialize_minimal_internal
is called before __libc_setup_tls in static binaries.
I have created an ugly patch to verify my hypothesis (attached). With
that patch the test program works, but what is the proper way to solve
this issue?
Does this happen only when uClibc itself is compiled with stack
protection? Or just when the pthread app is statically linked and
compiled with -fstack-protector?
With uClibc 0.9.33.x the same thing happens. With
glibc the program
works.
I can reproduce the bug. Moving __libc_setup_tls from NPTL init to
__uClibc_main.c fixes it. Why do you think it is ugly to do this?
Does attached patch works for you? Just a cleaned up version of your
fix. It doesn't produce any regressions running the testsuite.
best regards
Waldemar
16 Sep
16 Sep
6:41 a.m.
New subject: problem with stack protection, threads and static binaries
Hi Waldemar,
On Mon, 2015-09-14 at 06:52 +0200, Waldemar Brodkorb wrote:
With my patch __libc_setup_tls() was called twice. I also haven't
thought it through if if is ok to simply move it from the pthread code
or if something else is depending on it being there.
...
Does this happen only when uClibc itself is compiled with stack
protection? Or just when the pthread app is statically linked and
compiled with -fstack-protector?
This only happen when libpthread.a is compiled with stack protection and
the binary is statically linked. I have tried compiling the app both
with and without -fstack-protector-all but that doesn't change the
behavior. A libpthread.a not compiled with stack protection also does
not show this behavior.
With uClibc
0.9.33.x the same thing happens. With glibc the program
works.
I can reproduce the bug. Moving __libc_setup_tls from NPTL init to
__uClibc_main.c fixes it. Why do you think it is ugly to do this? Does attached patch works for you? Just a cleaned up
version of your
fix. It doesn't produce any regressions running the testsuite.
Yes, that patch works just fine. I have tested it on my limited test
case as well as in the environment where I first encountered the bug.
Thanks and best regards,
Daniel Fahlgren
17 Sep
17 Sep
6:02 p.m.
New subject: problem with stack protection, threads and static binaries
Hi Daniel,
Daniel Fahlgren wrote,
Hi Waldemar,
On Mon, 2015-09-14 at 06:52 +0200, Waldemar Brodkorb wrote:
With my patch __libc_setup_tls() was called twice. I also haven't
thought it through if if is ok to simply move it from the pthread code
or if something else is depending on it being there.
I still get segfaults when using __UCLIBC_HAS_SSP__ while compiling
uClibc-ng and then use the results to statically link your test app
with -fstack-protector-all. Gdb shows:
(gdb) bt
#0 0x000000000040cf1b in _dl_aux_init ()
So it seems not completely solved, yet.
Any idea?
best regards
Waldemar
...
Does this happen only when uClibc itself is compiled with stack
protection? Or just when the pthread app is statically linked and
compiled with -fstack-protector?
This only happen when libpthread.a is compiled with stack protection and
the binary is statically linked. I have tried compiling the app both
with and without -fstack-protector-all but that doesn't change the
behavior. A libpthread.a not compiled with stack protection also does
not show this behavior.
With
uClibc 0.9.33.x the same thing happens. With glibc the program
works.
I can reproduce the bug. Moving __libc_setup_tls from NPTL init to
__uClibc_main.c fixes it. Why do you think it is ugly to do this? Does attached patch works for you? Just a cleaned
up version of your
fix. It doesn't produce any regressions running the testsuite.
Yes, that patch works just fine. I have tested it on my limited test
case as well as in the environment where I first encountered the bug.
22 Sep
22 Sep
5:33 a.m.
New subject: problem with stack protection, threads and static binaries
Hi Waldemar,
On tor, 2015-09-17 at 20:02 +0200, Waldemar Brodkorb wrote:
I still get segfaults when using __UCLIBC_HAS_SSP__
while compiling
uClibc-ng and then use the results to statically link your test app
with -fstack-protector-all. Gdb shows:
(gdb) bt
#0 0x000000000040cf1b in _dl_aux_init ()
So it seems not completely solved, yet.
Any idea?
Strange, I fail to reproduce this issue when using buildroot. How to
you build uClibc-ng and what kind of OS / environment / toolchain /
etc do you have?
Best regards,
Daniel
11 Oct
11 Oct
5:12 p.m.
New subject: problem with stack protection, threads and static binaries
Hi Daniel,
Daniel Fahlgren wrote,
Hi Waldemar,
On tor, 2015-09-17 at 20:02 +0200, Waldemar Brodkorb wrote:
I am using OpenADK for my runtime testing before pushing changes to
uClibc-ng repository. But the problem seems ADK specific, when SSP
is enabled. Need to analyze it further, but the fix will be included
in 1.0.7, I promise :)
best regards
Waldemar
I still get segfaults when using
__UCLIBC_HAS_SSP__ while compiling
uClibc-ng and then use the results to statically link your test app
with -fstack-protector-all. Gdb shows:
(gdb) bt
#0 0x000000000040cf1b in _dl_aux_init ()
So it seems not completely solved, yet.
Any idea?
Strange, I fail to reproduce this issue when using buildroot. How to
you build uClibc-ng and what kind of OS / environment / toolchain /
etc do you have?
3142
days inactive
3173
days old
5 comments
2 participants
participants (2)
-
Daniel Fahlgren -
Waldemar Brodkorb