On 22/08/2016 22:33, Scott Ware wrote:
On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm <jb-open...@wisemo.com
<mailto:jb-open...@wisemo.com>>wrote:
On 22/08/2016 20:09, Scott Ware wrote:
We use libeay32.dll and ssleay32.dll from
https://slproweb.com/products/Win32OpenSSL.htmlin
<https://slproweb.com/products/Win32OpenSSL.htmlin>our
applications and we recently moved from version 1.0.2a to
1.0.2g and now on a few machines running a AMD Geode processor
we are getting "Unhandled exception at 0x005904dc
(libeay32.dll) in Test.exe: 0xC000001D: Illegal Instruction".
We ended up building OpennSSL so we could debug into it and
found it is failing on "movsd xmm0,mmword" (see below) which
the AMD Geode does not seem to support. I have tried "SET
OPENSSL_ia32cap=~0x1000000", "SET OPENSSL_ia32cap=~0x2000000",
and "SET OPENSSL_ia32cap=~0x7000000"; and nothing seems to
change. I may not be using OPENSSL_ia32cap correctly. This
happens when calling SSL_CTX_new which then calls RAND_add.
Any ideas on the best thing to do? We don't want to have to
manage different compiled versions of libeay32.dll and
ssleay32.dll if we can help it.
Your disassembly looks like the C compiler was invoked with
options that caused regular C floating point code (in this
case, the passing of 45.0 as an argument to RAND_add()) to
be compiled into MMX/SSE instructions instead of backwards
compatible 80x87 floating point instructions or (for simple
cases like this) regular integer unit data movement
instructions (such as two pushes of 32 bit constants that
contain the halves of the 64 bit double constant, which
would have been more efficient on every x86 CPU).
Did the build scripts or other source code contain any
differences from the official source code that can be
downloaded from openssl.org <http://openssl.org>?
How did you invoke the build scripts (command sequence,
special build environment, special environment variables
etc.)?
Which compiler and compiler version/edition did you use?
It would be interesting to know if one of the common Windows
compilers does this unconditionally, making it unsuitable
for use in programs that need to be backwards compatible.
I compiled using this process and seem to be getting the same result
as the .dll I downloaded from slproweb.com <http://slproweb.com>
I downloaded the 1.0.2g source from openssl.com
<http://openssl.com>and didn't change anything.
From the "Developer Command Promt for VS2013"
perl Configure debug-VC-WIN32 no-asm --prefix=C:\OpenSSL-VC-32-dbg
ms\do_ms
nmake -f ms\ntdll.mak
nmake -f ms\ntdll.mak install
According to the following page
https://msdn.microsoft.com/en-us/library/7t5yh4fd%28v=vs.120%29.aspx
Visual Studio 2012 and later requires the following compiler
option to generate code compatible with older CPUs (this is the
default in Visual Studio 2010, and VS2010 does not support the
option):
/arch:IA32
This compiler gotcha is specific to the 32 bit x86 architecture,
the default looks like it is still sane for x86_64.
Note to the FIPS team: Please check if this affects the FIPS
module building procedure.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
