Even specifying a different base address doesn't fix the problem. I have a different default address that the DLL consistently gets relocated to but changing the preferred base address of libeay32 to that address still doesn't work. The DLL will just get relocated to a different address. Using the /FIXED parameter also doesn't work. However, if you link a Visual Studio 2008 generated FIPS canister to a Visual Studio 2010 OpenSSL DLL then everything works. Unfortunately, that means your OpenSSL DLL is linked to both the VC9 CRT and the VC10 CRT which is exactly what I want to avoid. Strangely, the out32dll/fips_test_suite.exe no longer returns a failure after I compiled everything with the /FIXED linker option (everything was compiled with VS 2010). I assumed the test suite was linking to the generated OpenSSL DLLs but after running it through process explorer and dependency walker it looks like it's statically linked. Using the DLLs in my app still fails to initialize FIPS and the DLL is still getting relocated. I'm going to try static linking next.
> From: aerow...@gmail.com > To: openssl-dev@openssl.org > Date: Sun, 17 Oct 2010 09:27:21 -0700 > Subject: Re: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests > > Ugh. This is worse than I thought. It's *intermittently* failing like that. > After a few more minutes, I tried it again, and got the expected output. > > Is there some way to specify a base address during the creation of the DLL, > after the fipscanister is created? Would that invalidate it? > > The default appears to be 0x00d60000, and it works when loaded there. > > -Kyle H > > On Sun, Oct 17, 2010 at 9:17 AM, <aerow...@gmail.com> wrote: > > Dr Henson: > > > > I just built fips-1.2 under VS2010 (from a Visual Studio 2010 command > > prompt, under Windows Server 2008 [not 2008R2]). Running > > out32dll\openssl.exe itself, with environment OPENSSL_FIPS=1, returns: > > > > C:\openssl-fips-1.2\openssl-fips-1.2\out32dll>openssl > > 5324:error:2D06906E:FIPS routines:FIPS_CHECK_INCORE_FINGERPRINT:fingerprint > > does not match:.\fips\fips.c:238: > > > > I'm running under Windows Server 2008, which uses the Vista codebase instead > > of the Windows 7 codebase. > > > > If you would like me to send you any of my output files, I will, and if you > > would like me to do anything with the source, I will. (This particular > > build was ms\do_ms.bat no-asm.) > > > > -Kyle H > > > > On Sun, Oct 17, 2010 at 5:04 AM, Dr. Stephen Henson <st...@openssl.org> > > wrote: > >> > >> On Sat, Oct 16, 2010, Grant Averett wrote: > >> > >>> > >>> Hello, I've successfully built the validated FIPS object module and > >>> OpenSSL > >>> 0.9.8o on Windows with Visual Studio 2008 many times (both an x86 and x64 > >>> version) without issue and I can successfully build both with Visual > >>> Studio > >>> 2010. However, the FIPS module built with Visual Studio 2010 fails the > >>> FIPS > >>> test suite (out32dll\fips_test_suite.exe) and if I use the generated > >>> object > >>> module to build FIPS validated OpenSSL DLLs, those DLLs also fail the > >>> self > >>> test and can't be used to enable FIPS mode (OpenSSL reports "the > >>> fingerprint > >>> does not match"). > >>> > >>> > >>> "out32dll\fips_test_suite.exe" reports the following output when run > >>> right > >>> after "ms\do_fips.bat": 1. Non-Approved cryptographic operation test... > >>> a. Included algorithm (D-H)...successful2. Automatic power-up self > >>> > >>> test...ERROR:2d06906e:lib=45,func=105,reason=110:file=.\fips\fips.c:line=238:FAILED! > >>> > >>> > >>> The only difference between a working FIPS build and the failed build is > >>> the > >>> Visual Studio environment. The working version is built using Visual > >>> Studio > >>> 2008 SP1 and the failed with 2010 (both using the Professional edition > >>> and > >>> both on Windows 7). I've done a little investigation and it appears the > >>> 2010 version of libeay32.dll is being relocated from the correct > >>> preferred > >>> base address of 0xFB00000 to a different address. I have no idea why this > >>> is > >>> happening and nothing I do seems to prevent the relocation. I made sure > >>> to > >>> turn off image randomization and even tried changing the base address of > >>> the > >>> DLL during building using the command line option but it still gets > >>> relocated when I try to use it. If I use the Visual Studio > >>> 2008-generated > >>> DLLs in place of the 2010 DLLs then they work fine and are not relocated. > >>> It is very strange. However, since the FIPS module itself fails the FIP > >>> self-test I'm not sure this is significant. If I use a static library > >>> instead of the shared library OpenSSL DLL build the results are still the > >>> same when I try to enable FIPS mode... "the fingerprint does not match". > >>> I'm getting the "FIPS_R_FINGERPRINT_DOES_NOT_MATCH" error and not the > >>> "FIPS_R_FINGERPRINT_DOES_NOT_MATCH_NONPIC_RELOCATED" error so I have a > >>> feeling fixing the canister problem will fix the relocation issue with > >>> the > >>> DLL. > >>> > >>> I've tried everything I can think of and I'm running out of ideas. Does > >>> anyone have any suggestions on what could be the problem? Has anyone > >>> successfully built and tested the FIPS canister with Visual Studio 2010? > >>> > >> > >> I don't have access to Visual Studio 2010 so I can't reproduce this, I'm > >> wondering if some new feature in Windows 7 which VS 2010 makes use of is > >> interfering with the fingerprinting process. > >> > >> What happens if you specify /FIXED when you build the DLL? > >> > >> Steve. > >> -- > >> Dr Stephen N. Henson. OpenSSL project core developer. > >> Commercial tech support now available see: http://www.openssl.org > >> ______________________________________________________________________ > >> OpenSSL Project http://www.openssl.org > >> Development Mailing List openssl-dev@openssl.org > >> Automated List Manager majord...@openssl.org > >> > > > > >
