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. 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.
Note, this issue was seen on a Fedora release 18 (Spherical Cow). It
does not occur on the RedHat 6.3 release. 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.
Steps to recreate the problem:
# cat testppc.c
#include <openssl/evp.h>
int
main (int argc, char **argv)
{
OpenSSL_add_all_algorithms();
// Do nothing
EVP_cleanup();
return 0;
}
# gcc -m32 -lssl -lcrypto -o testppc testppc.c
******************
Running the testppc program under valgrind (as below) will result in a
very ugly error message. This is because valgrind was trying
(unsuccessfully) to handle the rldicl instruction in a 32-bit program.
The valgrind error does not mention the rldicl directly; we had to run
valgrind with debug options to seem the failing assembly instruction.
Since the rldicl instruction is not supported (as stated in the ISA) in
32-bit mode, Valgrind should probably just exit in a more graceful way.
The upshot is that for the purposes of investigating the problematic use
of rldicl in libcrypto, the ugly valgrind error should just be ignored.
The purpose of running the testppc program under valgrind is simply to
demonstrate that the rldicl is being used.
******************
# valgrind ./testppc
==27547== Memcheck, a memory error detector
==27547== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et
al.
==27547== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright
info
==27547== Command: ./testppc
==27547==
op name: And64
op type is (I64,I64) -> I64
arg tys are (I32,I64)
IR SANITY CHECK FAILURE
IRSB {
t0:I32 t1:I32 t2:I32 t3:I32 t4:F64 t5:F64 t6:I32 t7:I64
t8:I32 t9:I32 t10:I32 t11:I32 t12:I32 t13:I32 t14:I32
t15:I32
t16:I32 t17:I32 t18:I32 t19:I32 t20:I32
IR-NoOp
IR-NoOp
IR-NoOp
IR-NoOp
IR-NoOp
IR-NoOp
IR-NoOp
IR-NoOp
IR-NoOp
IR-NoOp
IR-NoOp
IR-NoOp
IR-NoOp
IR-NoOp
IR-NoOp
------ IMark(0xFCDD860, 4, 0) ------
PUT(1156) = 0xFCDD864:I32
------ IMark(0xFCDD430, 4, 0) ------
PUT(1152) = 0xFCDD430:I32
t9 = GET:I32(1184)
t8 = And32(t9,0x3:I32)
t5 = GET:F64(144)
t7 = ReinterpF64asI64(t5)
t4 = I64StoF64(Xor32(t8,And32(Shl32(t8,0x1:I8),0x2:I32)),t7)
PUT(144) = t4
------ IMark(0xFCDD434, 4, 0) ------
PUT(1152) = 0xFCDD434:I32
t10 = GET:I32(0)
t12 = GET:I32(0)
t11 =
And64(Mux0X(And8(0x20:I8,0x1F:I8),t10,Or32(Shl32(t10,And8(0x20:I8,0x1F:I8)),Shr32(t10,Sub8(0x20:I8,And8(0x20:I8,0x1F:I8))))),0xFFFFFFFF:I64)
PUT(0) = t11
------ IMark(0xFCDD438, 4, 0) ------
PUT(1152) = 0xFCDD438:I32
t18 = 0xFFFFFFFF:I32
t15 = t18
t19 = 0x1:I32
t16 = t19
t14 = And32(t16,t15)
t17 = And32(GET:I32(1156),0xFFFFFFFC:I32)
if (CmpEQ32(t14,0x0:I32)) goto {Boring} 0xFCDD43C:I32
goto {Return} t17
}
IN STATEMENT:
t11 =
And64(Mux0X(And8(0x20:I8,0x1F:I8),t10,Or32(Shl32(t10,And8(0x20:I8,0x1F:I8)),Shr32(t10,Sub8(0x20:I8,And8(0x20:I8,0x1F:I8))))),0xFFFFFFFF:I64)
ERROR = Iex.Binop: arg tys don't match op tys
... additional details precede BB printout
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
