> The OpenSSL library on Fedora 18 appears to use the routine > > .globl OPENSSL_ppc64_probe > .type OPENSSL_ppc64_probe,@function > .align 4 > OPENSSL_ppc64_probe: > fcfid 1,1 > rldicl 0,0,32,32 > blr > .long 0 > .byte 0,12,0x14,0,0,0,0,0 > > to try and determine if the hardware is 32-bit or 64-bit. The rldicl is > a 64-bit class instruction. On a 32-bit power processor it will > generate a SIGILL when the instruction is executed. The belief is that > the error handler then catches this and thus the OpenSSL package knows > it is running on a 32-bit platform. However, when the library is > compiled as a 32-bit library running on a 64-bit system the instruction > will execute without generating a SIGILL exception. Thus the library > might think it is running on a 64-bit system in 64-bit mode when it is > actually running in 32-bit mode.
Yes, and this is totally intentional. As long as a) CPU is 64-bit and b) kernel is 64-bit, even 32-bit processes can use 64-bit instructions such as rldicl. Yes, they actually *can* do so, but *only* as long as they are not hit by asynchronous signal. The thing is that 64-bit kernel preserves full 64-bit registers even for 32-bit processes upon context switch, but *not* upon signal delivery. Which is why you can observe sigprocmask in bn_mul_mont in the beginning of crypto/ppccap.c. See even "December 2009" comment in crypto/bn/asm/ppc64-mont.pl for why it's interesting to do that. > The concern is that the probe test may > not work as expected for a 32-bit binary running on a 64-bit system and > thus may give erroneous results. It shouldn't. What would be appropriate for Linux kernel to do is to arrange so that upper halves of 64-bit GP registers even upon signal delivery [which would allow to get rid of expensive setprocmask calls]. It's done on s390x platforms and one can do same even on PPC. For backward compatibility you'd have to save upper halves separately, but it can be done without having to recompile all the applications. > Note, this issue was seen on a Fedora release 18 (Spherical Cow). It > does not occur on the RedHat 6.3 release. 6.3 has 1.0.0, which doesn't perform the probe in question. > The issue was found when > running a test program using valgrind as valgrind detected a type > conflict. > > Maynard Johnson on the cc list can provide additional details if needed. You should be able to avoid this by setting OPENSSL_ppccap environment variable to 0 prior running the application under valgrid's control. This way you'll avoid the trouble with rldilc and have valgrind catch eventual problems. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
