Hi Natanael 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!
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? Last time I looked you pretty much mandated building an installation which only ran from ram?
However, your git tree suggests that you compile your uclibc without SSP? Can you comment on whether SSP works for you?
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)
OK, I'm going to try nptl now. (I couldn't actually get new linuxthreads to compile)
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
Thanks Ed W _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
