Van egy ilyen részlet a crypto/ppccpuid.s fájlban:
.globl .OPENSSL_altivec_probe
.align 4
.OPENSSL_altivec_probe:
.long 0x10000484
blr
.long 0
.byte 0,12,0x14,0,0,0,0,0
ami a debuggoláskor így néz ki:
Breakpoint 1, 0xdf530548 in OPENSSL_altivec_probe ()
from /usr/local/lib/libcrypto.so.1.0.1
(gdb) display/i $pc
1: x/i $pc
=> 0xdf530548 <OPENSSL_altivec_probe>: vor v0,v0,v0
(gdb) si
Program received signal SIGILL, Illegal instruction.
0xdf530548 in OPENSSL_altivec_probe () from /usr/local/lib/libcrypto.so.1.0.1
a hívó a crypto/ppccap.h, abban egy ilyesmi részlet van:
if (sigsetjmp(ill_jmp,1) == 0) {
OPENSSL_altivec_probe();
OPENSSL_ppccap_P |= PPC_ALTIVEC;
}
ez előtt volt egy sigaction, ami beállított egy handlert, ami lenyelné a hibát:
static void ill_handler (int sig) { siglongjmp(ill_jmp,sig); }
Namostan nekem van olyan helyzetem (Apache->Php->OpenSsl, továbbá saját PHP bővitmény is van), amikor ez valamiért nem így történik, hanem megáll a futás.
- 7095 megtekintés
Hozzászólások
Kezdek arra hajlani, hogy az OpenSsl ártatlan lehet, hanem a handlere valahogy érvényben maradt(???) és egy független SIGILL-t valamiért az ő rovására írtam. Természetesen a házi fejlesztés a leggyanúsabb, bár azért SIGILL-t C-ben előidézni nem annyira könnyű...
- A hozzászóláshoz be kell jelentkezni
Nem is nehez. Kell egy elkurt C compiler, vagy annak nem megfelelo parametere, egy elszurt asm betet, etc.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Á, egyszerűbb, szégyellem is elmondani;)
Elfelejtettem, hogy a dinamikus linker (/usr/lib/librtl.a(shr.o)) hiányában a dinamikus linkelés nem történik meg. Pontosabban, a következmények definiálatlanok, SIGILL éppúgy lehet belőle, mint látszólag helyes működés.
A gond ott kezdődik, hogy a PHP-bővítény futhat a stand-alone PHP-ben is, meg a libphp5.so-ban is, vagyis nem lehet előre megmondani, hogy honnan vegye az unresolved externjeit. Tehát kell a -brtllib opció -- mégpedig a főprogramnak, aki egyrészt a php, másrészt a httpd. Na ez utóbbi maradt ki.
Mégegyszer elnézést kérek az OpenSsl-től az alaptalan vádaskodásért.
- A hozzászóláshoz be kell jelentkezni
Na, az illegal instruction hetet tartjuk akkor. Nekem is volt tegnap egy ilyenem, egy Ubuntu Maverick szervert migraltam at egyik xenrol a masikra, es a ProFTPD egyik modulja a migracio utan megszunt mukodni a celgepen. tobbszor ujra is telepitettem a proftpd-t, sikertelenul, ugyhogy vegul disable lett a vege (nem hasznalt modul volt). Itt nem OpenSSL volt a ludas, hanem tcpwrapper nyug volt.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Hmmm... dump -H mit mond a modulra? És a főprogramra?
- A hozzászóláshoz be kell jelentkezni
Most nem tudom/akarom megnezni, de meg fogom mindenkepp.
PS: dump? Az nem valami AIX-es cucc? Igaz, hogy elrejtve, de utaltam arra, hogy Linux...
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Akkor ez nem volt nagy segítség neked, bocsi;)
(azért a readelf -d <module>.so-t meg lehet nézni, hátha van benne valami feltűnő.
Megj: readelf kimenetéből szerintem ezek a fontosak shared lib ügyben:
egrep '(NEEDED|SONAME|RPATH)')
- A hozzászóláshoz be kell jelentkezni
Koszi, megnezem. Fura, hogy egy sima rsync ilyen szinten bokjon el valamit.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni