From: Andrzej O. <an...@ma...> - 2010-03-22 23:55:19
|
Dears, In last compilations I see strange dynamic linker behaviour. Ofcourse, I see this when Asterisk dynamically loads and links modules, especially codecs compiled out of DL build process, but some driver built DL have this same problem. Asterisk run on compilation from begin of February (2.6.32.7) loads modules correctly. Asking with ldd about this modules gives correct result for all modules: > root@VoIP:/etc/asterisk/modules/bin162 # for f in $(ls *.so); do echo $f; ldd $f; done > codec_g723-ast16-gcc4-glibc-core2.so > linux-gate.so.1 => (0xb775a000) > /lib/libsafe.so.2 (0xb7715000) > libc.so.6 => /lib/libc.so.6 (0xb75e8000) > libdl.so.2 => /lib/libdl.so.2 (0xb75e4000) > /lib/ld-linux.so.2 (0xb775b000) > codec_g723-ast16-gcc4-glibc-pentium4-sse3.so > linux-gate.so.1 => (0xb770c000) > /lib/libsafe.so.2 (0xb76cd000) > libc.so.6 => /lib/libc.so.6 (0xb75a0000) > libdl.so.2 => /lib/libdl.so.2 (0xb759c000) > /lib/ld-linux.so.2 (0xb770d000) > codec_g729-ast16-gcc4-glibc-core2.so > linux-gate.so.1 => (0xb76f1000) > /lib/libsafe.so.2 (0xb7684000) > libc.so.6 => /lib/libc.so.6 (0xb7557000) > libdl.so.2 => /lib/libdl.so.2 (0xb7553000) > /lib/ld-linux.so.2 (0xb76f2000) > codec_g729-ast16-gcc4-glibc-pentium4-sse3.so > linux-gate.so.1 => (0xb778a000) > /lib/libsafe.so.2 (0xb771e000) > libc.so.6 => /lib/libc.so.6 (0xb75f1000) > libdl.so.2 => /lib/libdl.so.2 (0xb75ed000) > /lib/ld-linux.so.2 (0xb778b000) > root@VoIP:/etc/asterisk/modules/bin162 # But Asterisk built after i.e. yesterday (2.6.32.9) can't load this same modules. This same ask answers: > root@VoIP:/etc/asterisk/modules/bin162 # for f in $(ls *.so); do echo $f; ldd $f; done > codec_g723-ast16-gcc4-glibc-core2.so > not a dynamic executable > codec_g723-ast16-gcc4-glibc-pentium4-sse3.so > not a dynamic executable > codec_g729-ast16-gcc4-glibc-core2.so > not a dynamic executable > codec_g729-ast16-gcc4-glibc-pentium4-sse3.so > not a dynamic executable > root@VoIP:/etc/asterisk/modules/bin162 # I tried above ldd test on DL with standard build (without Asterisk and my upgrades) too. Result of lld differentiates in this same manner. Ofcourse on standard builds I can't check loadability by Asterisk, but if behavior of ldd listing of this this same modules differs between this builds in this same manner, problem in loading modules by Asterisk is probably because ot this same reason. So probably behavior of dynamic linker changed between this two version. But dynamic linker belongs to glibc and I checked this especially without any upgrades to glibc. Maybe anyone of You know source of problems? Between versions from Feb and from Mar was upgraded many packages and patches to kernel. How do You think? What changed behavior ot dynamic linking? Can we repair this (i.e. by downgrading any package)? Or this will be repaired with next kernels? or This is not repairable and we must wait for compatible recompilation of this modules? Regards -- Andrzej Odyniec |
From: Heiko Z. <he...@zu...> - 2010-03-24 12:30:53
|
Andrzej, not sure what would cause this behavior. Did you start with a completely new lfssystem when you compiled asterisk? If not, give that a try. Heiko Quoting Andrzej Odyniec <an...@ma...>: > Dears, > > In last compilations I see strange dynamic linker behaviour. > > Ofcourse, I see this when Asterisk dynamically loads and links modules, > especially codecs compiled out of DL build process, but some driver built DL > have this same problem. > > Asterisk run on compilation from begin of February (2.6.32.7) loads modules > correctly. Asking with ldd about this modules gives correct result for all > modules: >> root@VoIP:/etc/asterisk/modules/bin162 # for f in $(ls *.so); do >> echo $f; ldd $f; done >> codec_g723-ast16-gcc4-glibc-core2.so >> linux-gate.so.1 => (0xb775a000) >> /lib/libsafe.so.2 (0xb7715000) >> libc.so.6 => /lib/libc.so.6 (0xb75e8000) >> libdl.so.2 => /lib/libdl.so.2 (0xb75e4000) >> /lib/ld-linux.so.2 (0xb775b000) >> codec_g723-ast16-gcc4-glibc-pentium4-sse3.so >> linux-gate.so.1 => (0xb770c000) >> /lib/libsafe.so.2 (0xb76cd000) >> libc.so.6 => /lib/libc.so.6 (0xb75a0000) >> libdl.so.2 => /lib/libdl.so.2 (0xb759c000) >> /lib/ld-linux.so.2 (0xb770d000) >> codec_g729-ast16-gcc4-glibc-core2.so >> linux-gate.so.1 => (0xb76f1000) >> /lib/libsafe.so.2 (0xb7684000) >> libc.so.6 => /lib/libc.so.6 (0xb7557000) >> libdl.so.2 => /lib/libdl.so.2 (0xb7553000) >> /lib/ld-linux.so.2 (0xb76f2000) >> codec_g729-ast16-gcc4-glibc-pentium4-sse3.so >> linux-gate.so.1 => (0xb778a000) >> /lib/libsafe.so.2 (0xb771e000) >> libc.so.6 => /lib/libc.so.6 (0xb75f1000) >> libdl.so.2 => /lib/libdl.so.2 (0xb75ed000) >> /lib/ld-linux.so.2 (0xb778b000) >> root@VoIP:/etc/asterisk/modules/bin162 # > > > But Asterisk built after i.e. yesterday (2.6.32.9) can't load this same > modules. This same ask answers: >> root@VoIP:/etc/asterisk/modules/bin162 # for f in $(ls *.so); do >> echo $f; ldd $f; done >> codec_g723-ast16-gcc4-glibc-core2.so >> not a dynamic executable >> codec_g723-ast16-gcc4-glibc-pentium4-sse3.so >> not a dynamic executable >> codec_g729-ast16-gcc4-glibc-core2.so >> not a dynamic executable >> codec_g729-ast16-gcc4-glibc-pentium4-sse3.so >> not a dynamic executable >> root@VoIP:/etc/asterisk/modules/bin162 # > > I tried above ldd test on DL with standard build (without Asterisk and my > upgrades) too. Result of lld differentiates in this same manner. Ofcourse on > standard builds I can't check loadability by Asterisk, but if behavior of ldd > listing of this this same modules differs between this builds in this same > manner, problem in loading modules by Asterisk is probably because ot this > same reason. > > So probably behavior of dynamic linker changed between this two version. But > dynamic linker belongs to glibc and I checked this especially without any > upgrades to glibc. Maybe anyone of You know source of problems? Between > versions from Feb and from Mar was upgraded many packages and > patches to kernel. > > How do You think? What changed behavior ot dynamic linking? Can we > repair this > (i.e. by downgrading any package)? Or this will be repaired with > next kernels? > or This is not repairable and we must wait for compatible recompilation of > this modules? > > Regards > > -- > Andrzej Odyniec > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > -- Regards Heiko Zuerker http://www.devil-linux.org ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Andrzej O. <an...@ma...> - 2010-03-24 14:34:40
|
Heiko Zuerker wrote: > not sure what would cause this behavior. > Did you start with a completely new lfssystem when you compiled > asterisk? If not, give that a try. Heiko, Ofcourse. I always start with new lfssysytem. Problem is with loading by Asterisk drivers (codecs, shared libraries) built out of DL (asterisk.hosting.lv). Asterisk ends on segfault. The more, as author of compilation, Arkadi Shishlov said, IPP library, used to build this codecs is little fussy. With this librabies in DL context problem is new. Always all codecs was loaded successfully. I suspected myself upgraded glibc, so I returned to original 2.5.1. Because strange ldd results I traced ldd script and difference between compilation from Feb and Mar is in result of command: /lib/ld-linux.so.2 --verify ./codec_g723-ast16-gcc4-glibc-core2.so which gives other return code. But ld-linux.so.2 (dynamic linker) is binary the same in both environments. I found another parameter to ld-linux.so.2 --list and now I have description: > # /lib/ld-linux.so.2 --verify --list ./codec_g723-ast16-gcc4-glibc-core2.so > executable stack as shared object requires: Permission denied So I suspect, guilty is new kernel and new PAX. Now I started compilation with PAX switched off as grsecurity. Probably now kernel with PAX don't want to give rights for stack reservation as this library requires. I will report my results. Andrzej Odyniec |
From: Heiko Z. <he...@zu...> - 2010-03-28 14:00:32
|
> -----Original Message----- > From: Andrzej Odyniec [mailto:an...@ma...] > Sent: Wednesday, March 24, 2010 9:34 AM > To: dev...@li... > Subject: Re: [Devil-linux-develop] Dynamic linker behaviour > > Heiko Zuerker wrote: > > not sure what would cause this behavior. > > Did you start with a completely new lfssystem when you compiled > > asterisk? If not, give that a try. > > Heiko, > > Ofcourse. I always start with new lfssysytem. > > Problem is with loading by Asterisk drivers (codecs, shared > libraries) built > out of DL (asterisk.hosting.lv). Asterisk ends on segfault. The > more, as > author of compilation, Arkadi Shishlov said, IPP library, used to > build this > codecs is little fussy. > > With this librabies in DL context problem is new. Always all codecs > was loaded > successfully. I suspected myself upgraded glibc, so I returned to > original > 2.5.1. Because strange ldd results I traced ldd script and > difference between > compilation from Feb and Mar is in result of command: > > /lib/ld-linux.so.2 --verify ./codec_g723-ast16-gcc4-glibc-core2.so > > which gives other return code. But ld-linux.so.2 (dynamic linker) > is binary > the same in both environments. > > I found another parameter to ld-linux.so.2 --list and now I have > description: > > > # /lib/ld-linux.so.2 --verify --list ./codec_g723-ast16-gcc4- > glibc-core2.so > > executable stack as shared object requires: Permission denied > > So I suspect, guilty is new kernel and new PAX. Now I started > compilation with > PAX switched off as grsecurity. Probably now kernel with PAX don't > want to > give rights for stack reservation as this library requires. > > I will report my results. > > Andrzej Odyniec Okay great, let us know as soon as you have some results. If it is grsecurity/pax related, it may be a good idea to post something in their forum, maybe you can track down the issue and get the code fixed. I also started a new compile with a few updated packages, one of them the kernel 2.6.32.10, which also includes a newer grsecurity and pax. Heiko |
From: Heiko Z. <he...@zu...> - 2010-03-28 18:31:27
|
I just uploaded my updates, see if the latest kernel + grsec behave better for you. Heiko > -----Original Message----- > From: Heiko Zuerker [mailto:he...@zu...] > Sent: Sunday, March 28, 2010 9:00 AM > To: dev...@li... > Subject: Re: [Devil-linux-develop] Dynamic linker behaviour > > > -----Original Message----- > > From: Andrzej Odyniec [mailto:an...@ma...] > > Sent: Wednesday, March 24, 2010 9:34 AM > > To: dev...@li... > > Subject: Re: [Devil-linux-develop] Dynamic linker behaviour > > > > Heiko Zuerker wrote: > > > not sure what would cause this behavior. > > > Did you start with a completely new lfssystem when you compiled > > > asterisk? If not, give that a try. > > > > Heiko, > > > > Ofcourse. I always start with new lfssysytem. > > > > Problem is with loading by Asterisk drivers (codecs, shared > > libraries) built > > out of DL (asterisk.hosting.lv). Asterisk ends on segfault. The > > more, as > > author of compilation, Arkadi Shishlov said, IPP library, used to > > build this > > codecs is little fussy. > > > > With this librabies in DL context problem is new. Always all > codecs > > was loaded > > successfully. I suspected myself upgraded glibc, so I returned to > > original > > 2.5.1. Because strange ldd results I traced ldd script and > > difference between > > compilation from Feb and Mar is in result of command: > > > > /lib/ld-linux.so.2 --verify ./codec_g723-ast16-gcc4-glibc- > core2.so > > > > which gives other return code. But ld-linux.so.2 (dynamic linker) > > is binary > > the same in both environments. > > > > I found another parameter to ld-linux.so.2 --list and now I have > > description: > > > > > # /lib/ld-linux.so.2 --verify --list ./codec_g723-ast16-gcc4- > > glibc-core2.so > > > executable stack as shared object requires: Permission denied > > > > So I suspect, guilty is new kernel and new PAX. Now I started > > compilation with > > PAX switched off as grsecurity. Probably now kernel with PAX > don't > > want to > > give rights for stack reservation as this library requires. > > > > I will report my results. > > > > Andrzej Odyniec > > Okay great, let us know as soon as you have some results. If it is > grsecurity/pax related, it may be a good idea to post something in > their > forum, maybe you can track down the issue and get the code fixed. > > I also started a new compile with a few updated packages, one of > them > the kernel 2.6.32.10, which also includes a newer grsecurity and > pax. > > Heiko > > > ------------------------------------------------------------------- > ----------- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop |
From: Andrzej O. <an...@ma...> - 2010-03-30 13:21:21
|
Heiko Zuerker wrote: > I just uploaded my updates, see if the latest kernel + grsec behave > better for you. Thanks. There is no difference. With last Grsecurity/PaX I obtain as usually: > ./codec_g723-ast16-gcc4-glibc-core2-sse4.so: error while loading shared libraries: > ./codec_g723-ast16-gcc4-glibc-core2-sse4.so: cannot enable executable stack > as shared object requires: Permission denied So I sent this issue to proper author group http://groups.google.com/group/asterisk-g729/ and variant with Asterisk I'm compiling without Grsecurity. Regards -- Andrzej Odyniec |
From: Andrzej O. <an...@ma...> - 2010-03-29 10:15:53
|
Heiko Zuerker wrote: > Okay great, let us know as soon as you have some results. After some number of compilations with 2.6.32.9 I have clear, obvious relation between compilation with grsec and "unloadability" od codecs/librabies compiled with Intel IPP. I had problem with DAHDI drivers and GRSECured kernel some months ago, mainly with unloading DAHDI drivers, but this was corrected in newer versions of DAHDI. > If it is > grsecurity/pax related, it may be a good idea to post something in their > forum, maybe you can track down the issue and get the code fixed. If result will be repetitive on 2.6.32.10, I will check all asterisk modules. If from asterisk distribution there will be "unloadable" modules, this should be submitted to asterisk forum. But if only IPP compiled modules will be "unloadable", submit should be addressed to Asterisk G.729 Google group. But from other side, they know problems with SELinux, so there can be permanent problems with securing i.e. stacks with IPP compiled modules. In this situation maybe reasonable solution is to find proper grsec/PaX parameter and to relax it for compilation with asterisk if one want to use open g723.1 and g729 codecs. > I also started a new compile with a few updated packages, one of them > the kernel 2.6.32.10, which also includes a newer grsecurity and pax. So I start to try it Best Regards -- Andrzej Odyniec <an...@ma...> Rada Nadzorcza Macrologic SA ul. Chrościckiego 49, 02-414 Warszawa tel. +48-228637681, kom. +48-601276572 ul. Kłopotowskiego 22, 03-717 Warszawa tel. +48-225118115, fax: +48-225118117 Rejestr: Sąd Rejonowy dla m.st. Warszawy, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego, numer 0000045462 Numer identyfikacji podatkowej: PL 5220002825 Kapitał zakładowy: 1888719 zł opłacony w całości |