At Mon, 14 Apr 2003 12:48:00 +0200, mikee wrote: > > The malloc_initialize_hook is glibc's malloc() hook routine. I guess > > this program gets also sigsegv: > > > [snip] > > > > no sigsegv: > > mim:~# gcc -o testpax testpax.c > mim:~# ./testpax > malloc > mim:~# chpax -v testpax
Hmm, sorry my misunderstanding test program. > ----[ chpax 0.2 : Current flags for testpax ]---- > > * Paging based PAGE_EXEC : enabled (overridden) > * Trampolines : not emulated > * mprotect() : restricted > * mmap() base : randomized > * ET_EXEC base : not randomized > * Segmentation based PAGE_EXEC : enabled > > mim:~# grep PAX /var/log/syslog > mim:~# > > > Do you have any problems in X11 or java with pax? > i don't use x11 or java - that box is my lan gateway ;-) > > i also received mail from [EMAIL PROTECTED] (pax team): > > just saw your bugreport on debian. what happens here is that localedef > > uses gcc nested functions which are invoked by placing some small code > > on the stack which happens to be non-executable, hence the task will > > be killed. chpax -sp disables both kinds of non-exec features on the > > target (even if technically -s is enough since you didn't compile the > > other feature in the kernel). a better solution would be to rewrite > > localedef to not use nested functions. > > i suppose it explains the problem but solution depends on politics: > - patch glibc to be PAX/enhanced security/ friendly OR > - reconfigure PAX to be glibc friendly > i like first solution but i won't rewrite localedef tool myself > so this is my wish ;-) This means that all programs using gcc nested functions (so trampoline technique) are totally unusable on pax environment? And do you think "chpax.sh" is useful for this purpose? If so, I think the temporary solution is that chpax packages supports chpax.sh. Regards, -- gotom
