<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 22, 2016 at 8:05 PM, Jakob Bohm <span dir="ltr"><<a href="mailto:jb-openssl@wisemo.com" target="_blank">jb-openssl@wisemo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 22/08/2016 22:33, Scott Ware wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5">
<br>
On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm <<a href="mailto:jb-openssl@wisemo.com" target="_blank">jb-openssl@wisemo.com</a> <mailto:<a href="mailto:jb-openssl@wisemo.com" target="_blank">jb-openssl@wisemo.com</a>><wbr>>wrote:<br>
<br>
On 22/08/2016 20:09, Scott Ware wrote:<br>
<br>
We use libeay32.dll and ssleay32.dll from<br>
<a href="https://slproweb.com/products/Win32OpenSSL.htmlin" rel="noreferrer" target="_blank">https://slproweb.com/products/<wbr>Win32OpenSSL.htmlin</a><br>
<<a href="https://slproweb.com/products/Win32OpenSSL.htmlin" rel="noreferrer" target="_blank">https://slproweb.com/products<wbr>/Win32OpenSSL.htmlin</a>>our<br>
applications and we recently moved from version 1.0.2a to<br>
1.0.2g and now on a few machines running a AMD Geode processor<br>
we are getting "Unhandled exception at 0x005904dc<br>
(libeay32.dll) in Test.exe: 0xC000001D: Illegal Instruction".<br>
We ended up building OpennSSL so we could debug into it and<br>
found it is failing on "movsd xmm0,mmword" (see below) which<br>
the AMD Geode does not seem to support. I have tried "SET<br>
OPENSSL_ia32cap=~0x1000000", "SET OPENSSL_ia32cap=~0x2000000",<br>
and "SET OPENSSL_ia32cap=~0x7000000"; and nothing seems to<br>
change. I may not be using OPENSSL_ia32cap correctly. This<br>
happens when calling SSL_CTX_new which then calls RAND_add.<br>
<br>
Any ideas on the best thing to do? We don't want to have to<br>
manage different compiled versions of libeay32.dll and<br>
ssleay32.dll if we can help it.<br>
<br>
Your disassembly looks like the C compiler was invoked with<br>
options that caused regular C floating point code (in this<br>
case, the passing of 45.0 as an argument to RAND_add()) to<br>
be compiled into MMX/SSE instructions instead of backwards<br>
compatible 80x87 floating point instructions or (for simple<br>
cases like this) regular integer unit data movement<br>
instructions (such as two pushes of 32 bit constants that<br>
contain the halves of the 64 bit double constant, which<br>
would have been more efficient on every x86 CPU).<br>
<br>
Did the build scripts or other source code contain any<br>
differences from the official source code that can be<br></div></div>
downloaded from <a href="http://openssl.org" rel="noreferrer" target="_blank">openssl.org</a> <<a href="http://openssl.org" rel="noreferrer" target="_blank">http://openssl.org</a>>?<span class=""><br>
<br>
How did you invoke the build scripts (command sequence,<br>
special build environment, special environment variables<br>
etc.)?<br>
<br>
Which compiler and compiler version/edition did you use?<br>
<br>
It would be interesting to know if one of the common Windows<br>
compilers does this unconditionally, making it unsuitable<br>
for use in programs that need to be backwards compatible.<br>
<br>
<br>
<br></span>
I compiled using this process and seem to be getting the same result as the .dll I downloaded from <a href="http://slproweb.com" rel="noreferrer" target="_blank">slproweb.com</a> <<a href="http://slproweb.com" rel="noreferrer" target="_blank">http://slproweb.com</a>><br>
I downloaded the 1.0.2g source from <a href="http://openssl.com" rel="noreferrer" target="_blank">openssl.com</a> <<a href="http://openssl.com" rel="noreferrer" target="_blank">http://openssl.com</a>>and didn't change anything.<span class=""><br>
<br>
>From the "Developer Command Promt for VS2013"<br>
perl Configure debug-VC-WIN32 no-asm --prefix=C:\OpenSSL-VC-32-dbg<br>
ms\do_ms<br>
nmake -f ms\ntdll.mak<br>
nmake -f ms\ntdll.mak install<br>
</span></blockquote>
According to the following page<br>
<br>
<a href="https://msdn.microsoft.com/en-us/library/7t5yh4fd%28v=vs.120%29.aspx" rel="noreferrer" target="_blank">https://msdn.microsoft.com/en-<wbr>us/library/7t5yh4fd%28v=vs.120<wbr>%29.aspx</a><br>
<br>
Visual Studio 2012 and later requires the following compiler<br>
option to generate code compatible with older CPUs (this is the<br>
default in Visual Studio 2010, and VS2010 does not support the<br>
option):<br>
<br>
/arch:IA32<br>
<br>
<br>
This compiler gotcha is specific to the 32 bit x86 architecture,<br>
the default looks like it is still sane for x86_64.<br>
<br>
Note to the FIPS team: Please check if this affects the FIPS<br>
module building procedure.</blockquote><div><b><br></b></div>Jakob! Thank you so much! That was the issue.I added /arch:IA32 to the APP_CFLAG and LIB_CFLAG in ms\ntdll.mak and I was able to compile a new build that works on the problem machine. Is it worth doing a bug report on so they might add that to the build scripts? Without it it seems like the whole OPENSSL_ia32cap system is broken.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Before I had found this answer I had also installed nasm so I didn't have to do the no-asm. So My current build process is:</div><div class="gmail_quote"><div><br></div><div>From the "Developer Command Promt for VS2013"<br>perl Configure VC-WIN32 --prefix=C:\OpenSSL-VC-32-DLL<br>ms\do_ms</div><div>ms\do_nasm.bat</div><div>(Edit ms\ntdll.mak to add /arch:IA32 to the APP_CFLAG and LIB_CFLAG)</div><div>nmake -f ms\ntdll.mak<br>nmake -f ms\ntdll.mak install<br></div><div><br></div><div>Thank you Jakob and the OpenSSL mailing list for the quick answers!<br></div><div>- Scott Ware</div><div><br></div><div><br></div><div><br></div><div> </div></div></div></div>