Re: Problems with pthreads in a chroot?
Thanks to all who replied. I switched to current git master + nptl threads and all round I'm much happier! I'm only testing 32bit x86 nptl, but this seems like the best uClibc by far! The PAX issues with 0.9.31 appeared to be due to mmap segments requesting EXEC in the old thread code. I don't mean to second guess anyone, but given that the code base is currently such a big step forward (and been quiet for a while) is there a move to draw a line under this and move towards an imminent release? ie it would appear that for at least one architecture the code is in good shape? Thanks all Ed W ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Problems with pthreads in a chroot?
On Mon, Oct 18, 2010 at 9:40 PM, Ed W li...@wildgooses.com wrote: Hi Natanael Hi, Thanks for responding Or you could just use Alpine Linux[2]. After all, x86 uclibc + grsecurity kernel (including pax) is our main focus ;) Sure - actually my current project uses very similar to your alpine linux installation, only starting with a gentoo overlay. I would very happily share any improvements I make however, normally you are ahead of me and I usually find the solutions to most uclibc questions are in your tree! We used to use gentoo for building alpine. Now we stand on our own legs. I think I would struggle to switch to using your build tool at present because I'm trying to build a modular setup rather like slax. The idea is target a low ram target (which I think rules out running from ramdisk) and use aufs to build a modular installation where we have a base installation, but overlay more functionality for instances where it's needed. This would make for a very simple package manager. Please tell me that this would be straightforward to build using Alpine and we should talk more off-list? I think it should be fairly straightforward to get that working. We have someone working on a similar project to yours, with unionfs - but he wants use eglibc instead of uclibc. Might be we need some patches for supporting aufs in initramfs to mounting up the root, but I think thats gonna be trivial. You are welcome to freenode #alpine-devel or #alpine-linux to discuss details. Last time I looked you pretty much mandated building an installation which only ran from ram? We support installing on disk. I run Alpine Linux on my netbook as a traditional disk install. However, your git tree suggests that you compile your uclibc without SSP? Can you comment on whether SSP works for you? I thought we enable SSP? hum... looks like i need to fix the gcc apkbuild. SSP should work though. We used it for gcc-4.4 and i'm fixing gcc-4.5 as we speak. -- Natanael Copa ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Problems with pthreads in a chroot?
On 13/10/2010 23:43, Richard Braun wrote: On Wed, Oct 13, 2010 at 10:45:18PM +0100, Ed W wrote: I traced the workaround to either disabling PAX_MPROTECT in the host kernel, or calling paxctl -m on the test binary (was expecting to need it on the library instead?) Can anyone shed some light on why creating a pthread (old linux threads) on 0.9.30.1 / 0.9.31 should be tickling mprotect? Are you perfectly sure you're using the *old* LinuxThreads ? A quick look only revealed calls to mprotect() in the new implementation. Yes to using old linux threads However, after further digging this is starting to look like an interaction between newer pax and uclibc, eg perhaps pax 2.2 vs 2.1 is the cause (not yet debugged that far) It's taken me a little time to figure this out, but my build machine is 2.6.32 with pax 2.2 - I'm reasonably sure this used to work previously with an earlier pax patch. The kernel which was working on the final device was a 2.6.33 + pax 2.1, I just updated it to 2.6.35 + pax 2.2 and now I see exactly the same failure to create threads there Is it possible that someone smarter than me can please help me make uclibc 0.9.31 work with pax 2.2 patches? At least some pointers on how to debug and find the lines of code which are triggering the failure would be helpful? I have a temporary workaround to start fiddling with kernel patch sets on the final device, but I'm starting to get painted into a corner on the build machine... Thanks Ed W (Alternatively, how close are we to seeing 0.9.32 and nptl get out of the door? Seems like it's within spitting distance?) ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Problems with pthreads in a chroot?
Hi Ed, I assume you are using x86 uclibc. On Mon, Oct 18, 2010 at 6:16 PM, Ed W li...@wildgooses.com wrote: It's taken me a little time to figure this out, but my build machine is 2.6.32 with pax 2.2 - I'm reasonably sure this used to work previously with an earlier pax patch. The kernel which was working on the final device was a 2.6.33 + pax 2.1, I just updated it to 2.6.35 + pax 2.2 and now I see exactly the same failure to create threads there Is it possible that someone smarter than me can please help me make uclibc 0.9.31 work with pax 2.2 patches? At least some pointers on how to debug and find the lines of code which are triggering the failure would be helpful? I can share our Alpine Linux experiences with x86 uclibc and threading. We started with oldthreads, bumped into some bugs that was difficult to solve, switched to linuxthreads.new which worked more or less ok. You could have a look at the uclibc patches[1] alpine linux used for 0.9.30. We skipped the 0.9.31 release and jumped directly to git master/NPTL. Or you could just use Alpine Linux[2]. After all, x86 uclibc + grsecurity kernel (including pax) is our main focus ;) ... (Alternatively, how close are we to seeing 0.9.32 and nptl get out of the door? Seems like it's within spitting distance?) fwiw, for us the nptl from git have been better/more stable than any other threading implementation before. Infact, for x86, uclibc git master have been better than any previous release, ever. (at least up to the point config parser stuff got committed - but i think those issues are fixed to now) -- Natanael Copa [1] http://git.alpinelinux.org/cgit/aports/tree/main/uclibc?h=1.10-stable [2] http://alpinelinux.org ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Problems with pthreads in a chroot?
On Mon, Oct 18, 2010 at 08:40:19PM +0100, Ed W wrote: Incidently I had a response from Brad at grsec: Can you check for calls to mmap with PROT_READ | PROT_WRITE | PROT_EXEC? uclibc is likely trying to create executable stacks. Removing the PROT_EXEC in the protection flags in the source should solve the problem. Otherwise you'll have to turn mprotect off on the binaries, as PaX no longer silently demotes RWX mappings to RW. -Brad Can anyone smarter than me comment on that? I do in fact see such a call in linuxthreads.old/manager.c It's quite likely. Give a try to strace and see if the failure happens for that call. -- Richard Braun ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Problems with pthreads in a chroot?
On 18/10/2010 20:28, Natanael Copa wrote: fwiw, for us the nptl from git have been better/more stable than any other threading implementation before. Infact, for x86, uclibc git master have been better than any previous release, ever. (at least up to the point config parser stuff got committed - but i think those issues are fixed to now) Any chance of a little help here please: Grabbed latest git, compiled using the .config from Natanael's alpine git, I get near the end the following compile error: (http://git.alpinelinux.org/cgit/aports/plain/main/libc0.9.32/uclibcconfig.x86) CC libpthread/nptl/sysdeps/unix/sysv/linux/jmp-unwind.os libpthread/nptl/sysdeps/unix/sysv/linux/jmp-unwind.c:29: warning: no previous prototype for '_longjmp_unwind' AS libpthread/nptl/sysdeps/unix/sysv/linux/close.os AS libpthread/nptl/sysdeps/unix/sysv/linux/open.os AS libpthread/nptl/sysdeps/unix/sysv/linux/write.os AS libpthread/nptl/sysdeps/unix/sysv/linux/read.os AS libpthread/nptl/sysdeps/unix/sysv/linux/waitpid.os CC libpthread/nptl/alloca_cutoff.os libpthread/nptl/alloca_cutoff.c:27: warning: no previous prototype for '__libc_alloca_cutoff' CC libpthread/nptl/libc-cancellation.os CC libpthread/nptl/sysdeps/generic/libc-tls.os libpthread/nptl/sysdeps/generic/libc-tls.c:114: warning: no previous prototype for '__libc_setup_tls' libpthread/nptl/sysdeps/generic/libc-tls.c:249: warning: no previous prototype for '__pthread_initialize_minimal' CC libpthread/nptl/sysdeps/generic/dl-tls.os libpthread/nptl/sysdeps/generic/dl-tls.c:69: warning: no previous prototype for '_dl_memalign' libpthread/nptl/sysdeps/generic/dl-tls.c:840: warning: no previous prototype for '_dl_add_to_slotinfo' CC libc/sysdeps/linux/common/ssp-local.os CC libc/misc/elf/dl-support.os CC libc/misc/elf/dl-core.os CC libc/misc/elf/dl-iterate-phdr.os CC libc/misc/internals/__uClibc_main.os libc/misc/internals/__uClibc_main.c: In function '__uClibc_main': libc/misc/internals/__uClibc_main.c:484: warning: nested extern declaration of '__nptl_deallocate_tsd' libc/misc/internals/__uClibc_main.c:494: warning: nested extern declaration of '__nptl_nthreads' CC libc/inet/rpc/rpc_thread.os CC libc/stdlib/atexit.os CC libc/stdlib/system.os AR cr lib/libc.a STRIP -x -R .note -R .comment lib/libc.a AR cr lib/uclibc_nonshared.a STRIP -x -R .note -R .comment lib/uclibc_nonshared.a AR cr libc/libc_so.a STRIP -x -R .note -R .comment libc/libc_so.a LD libuClibc-0.9.32-git.so libc/libc_so.a(sigaction.os): In function `sigaction': sigaction.c:(.text.__sigaction+0x20): undefined reference to `__emutls_get_address' libc/libc_so.a(close.oS): In function `__GI___close_nocancel': (.text+0x55): undefined reference to `__libc_errno' collect2: ld returned 1 exit status make: *** [lib/libc.so] Error 1 Software versions: gcc version 4.4.4 (Gentoo Hardened 4.4.4-r2 p1.2, pie-0.4.5) GNU Make 3.81 build root running uclibc-0.9.31 I think this is a gcc specific issue right? Or is it related to trying to build uclibc on uclibc? Grateful for any pointers Thanks Ed W ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Problems with pthreads in a chroot?
On Wed, Oct 13, 2010 at 10:45:18PM +0100, Ed W wrote: I traced the workaround to either disabling PAX_MPROTECT in the host kernel, or calling paxctl -m on the test binary (was expecting to need it on the library instead?) Can anyone shed some light on why creating a pthread (old linux threads) on 0.9.30.1 / 0.9.31 should be tickling mprotect? Are you perfectly sure you're using the *old* LinuxThreads ? A quick look only revealed calls to mprotect() in the new implementation. -- Richard Braun ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
