FS#15454 - [openssl] i686 pkg compiled with SSE2 code

Attached to Project: Arch Linux
Opened by Gerardo Exequiel Pozzi (djgera) - Thursday, 09 July 2009, 07:07 GMT
Last edited by Roman Kyrylych (Romashka) - Thursday, 09 July 2009, 19:25 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Pierre Schmitz (Pierre)
Architecture i686
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: libcrypto.so.0.9.8 contains many SSE2 instructions in openssl-0.9.8k-2.

Solution: add to ./config the flag "no-sse2"

$ objdump -d /usr/lib/libcrypto.so.0.9.8 | grep "movdq.*xmm"
This task depends upon

Closed by  Roman Kyrylych (Romashka)
Thursday, 09 July 2009, 19:25 GMT
Reason for closing:  Not a bug
Additional comments about closing:  SSE2 are detected at runtime.
Comment by Gerardo Exequiel Pozzi (djgera) - Thursday, 09 July 2009, 07:07 GMT
Sidenote: When compiled with GCC 4.4.0 show one warning about strict aliasing breaking in file crypto/dso/dso_dlfcn.c. So I tried to compile with -fno-strict-aliasing to compare the output and view if the output object is bad. Result: in this case no problem, compiling with or without -fno-strict-aliasing produces the same output object.


$ gcc -I.. -I../.. -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -c -o dso_dlfcn.o dso_dlfcn.c
dso_dlfcn.c: In function 'dlfcn_bind_func':
dso_dlfcn.c:258: warning: dereferencing pointer 'tsym.23' does break strict-aliasing rules
dso_dlfcn.c:258: note: initialized from here

$ md5sum dso_dlfcn.o
168dbe85ffe93dd5cca2e86b0e81327a dso_dlfcn.o

$ gcc -I.. -I../.. -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -fno-strict-aliasing -c -o dso_dlfcn.o dso_dlfcn.c

$ md5sum dso_dlfcn.o
168dbe85ffe93dd5cca2e86b0e81327a dso_dlfcn.o
Comment by Pierre Schmitz (Pierre) - Thursday, 09 July 2009, 10:10 GMT
Is this really a problem? According to the openssl readme its detected on runtime whether sse2 is used or not:


no-sse2 Exclude SSE2 code pathes. Normally SSE2 extention is
detected at run-time, but the decision whether or not the
machine code will be executed is taken solely on CPU
capability vector. This means that if you happen to run OS
kernel which does not support SSE2 extension on Intel P4
processor, then your application might be exposed to
"illegal instruction" exception. There might be a way
to enable support in kernel, e.g. FreeBSD kernel can be
compiled with CPU_ENABLE_SSE, and there is a way to
disengage SSE2 code pathes upon application start-up,
but if you aim for wider "audience" running such kernel,
consider no-sse2. Both 386 and no-asm options above imply
no-sse2.
Comment by Pierre Schmitz (Pierre) - Thursday, 09 July 2009, 10:28 GMT
For the aliasing issue: We might want to add this patch by Fedora/IBM: http://cvs.fedoraproject.org/viewvc/rpms/openssl/devel/openssl-0.9.8b-aliasing-bug.patch?revision=1.1&view=markup
Comment by Gerardo Exequiel Pozzi (djgera) - Thursday, 09 July 2009, 19:13 GMT
Yes, after having reported this, I thought (in dreams), "how many people use these routines in a Pentium II / III" and these was no problem"
Anyway I verified on emulated pentium2(qemu) tracing if the function sha512_block_sse2() is executed on "openssl sha -sha512", and no execution is made :)

PS: Good patch for aliasing ;)


Closing...

Loading...