Re: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests
On 10/17/2010 4:36 PM, Dr. Stephen Henson wrote: On Sun, Oct 17, 2010, aerow...@gmail.com wrote: 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 0x00d6, and it works when loaded there. You can't modify the 1.2 module build process in any way but you can specify an alternate base address when you link against a newer version of OpenSSL such as 0.9.8o. One way to get more information would be to dump the fingerprinted data in the FIPS_incore_fingerprint() function along with the addresses when it works and when it fails. Then see if the addresses and/or the dumped binary data have changed. On Windows it is not possible to require that a DLL be loaded at a specific address in memory within a process. The base address is simply a recommendation and if correct will result in the library loading process being faster than if it is not. Any fingerprinting of a library needs to be performed by computing the memory offsets compared to the base address and using those. Microsoft Vista, Server 2008, Win7 and Server 2008-R2 all support enable by default Address space layout randomization (ASLR). Visual Studio 2010 is the first version of Windows development tools to turn ASLR on by default for EXEs and DLLs. To disable, use /DYNAMICBASE:NO when linking. (Or disable the Randomized Base Address property in Visual Studio.) Jeffrey Altman Secure Endpoints, Inc. signature.asc Description: OpenPGP digital signature
RE: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests
Thanks Jeffrey. I was aware of the limitation and how image randomization works in Vista and higher so disabling ASLR was the first thing I tried. Unfortunately, disabling ASLR didn't fix the problem. The DLL gets relocated with or without ASLR enabled. The VC9-generated DLL does not have this problem. It always loads at the correct base address. Since the FIPS canister fails its self-test (before the OpenSSL DLL is ever generated with it), I suspect the problem is more significant than the DLL not residing at the correct address. I know the DLL will fail if it doesn't reside at the correct address but I suspect the relocation is a symptom of a larger issue. Statically linking with the OpenSSL FIPS library reports the exact same error (Incorrect fingerprint) as when linking to the DLL. I would be happy to try any additional suggestions. Thanks,Grant Date: Mon, 18 Oct 2010 09:54:18 -0400 From: jalt...@secure-endpoints.com To: openssl-dev@openssl.org Subject: Re: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests On 10/17/2010 4:36 PM, Dr. Stephen Henson wrote: On Sun, Oct 17, 2010, aerow...@gmail.com wrote: 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 0x00d6, and it works when loaded there. You can't modify the 1.2 module build process in any way but you can specify an alternate base address when you link against a newer version of OpenSSL such as 0.9.8o. One way to get more information would be to dump the fingerprinted data in the FIPS_incore_fingerprint() function along with the addresses when it works and when it fails. Then see if the addresses and/or the dumped binary data have changed. On Windows it is not possible to require that a DLL be loaded at a specific address in memory within a process. The base address is simply a recommendation and if correct will result in the library loading process being faster than if it is not. Any fingerprinting of a library needs to be performed by computing the memory offsets compared to the base address and using those. Microsoft Vista, Server 2008, Win7 and Server 2008-R2 all support enable by default Address space layout randomization (ASLR). Visual Studio 2010 is the first version of Windows development tools to turn ASLR on by default for EXEs and DLLs. To disable, use /DYNAMICBASE:NO when linking. (Or disable the Randomized Base Address property in Visual Studio.) Jeffrey Altman Secure Endpoints, Inc.
Re: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests
On Mon, Oct 18, 2010, Grant Averett wrote: 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. Yes the FIPS test utilities including fips_test_suite.exe are statically linked against fipscanister.lib this was to demonstrate that those utilities have no dependencies on any unvalidated source code. I'd suggest writing a test application that just enters FIPS mode and see the result. Then get it to dump the addresses of the fingerprinted regions and their contents: then a comparison can be done to see if the contents change even if the addresses are the same. -- 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
Re: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests
Question #1. Are we talking about 32-bit version or is it the problem with *both* x86 and x64 code? 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. Define also doesn't work. If I link *both* fips_test_suite.exe *and* libeay.dll with /FIXED (or /DYNAMICBASE:NO), then both fips_test_suite.exe and openssl.exe with OPENSSL_FIPS environment variable set work. With fips_test_suite.exe working, because it itself is linked with /FIXED, and openssl.exe working because libeay32.dll is linked with /FIXED. However, if you link a Visual Studio 2008 generated FIPS canister to a Visual Studio 2010 OpenSSL DLL then everything works. Strange... It's up to linker to set dynamicbase flag in COFF header. Newer compiler must be marking .obj files in some special way, which serves as a message to linker. 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. Originally fipscanister.lib was designed not to have strong dependency on msvcrt, meaning that idea was that it should be possible to use fipscanister compiled with one compiler with another. But it was verified to work with rather old compilers. 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. Is libeay32.dll linked with /FIXED? Verify with 'dumpbin /headers libeay32.dll', look for DLL characteristics. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests
On Windows it is not possible to require that a DLL be loaded at a specific address in memory within a process. The base address is simply a recommendation and if correct will result in the library loading process being faster than if it is not. Correct and prerequisite for recommended base address is respected is its, address's, availability. Reasoning was that if it's not the case one would have to ensure it in some way, most notably by linking OpenSSL first. Any fingerprinting of a library needs to be performed by computing the memory offsets compared to the base address and using those. The trouble is that code emitted by Windows compilers is not position-independent, meaning that relocations, offsets fix-ups, reside [among other things] in .text segment. My understanding is that it's x86 compilers that are at-fault, x64 code should be position-independent... Microsoft Vista, Server 2008, Win7 and Server 2008-R2 all support enable by default Address space layout randomization (ASLR). Visual Studio 2010 is the first version of Windows development tools to turn ASLR on by default for EXEs and DLLs. To disable, use /DYNAMICBASE:NO when linking. (Or disable the Randomized Base Address property in Visual Studio.) I can confirm that /FIXED have similar effect. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] Openssl asm BN/AES/SHA1 acceleration for SH4 and MIPS32
Vincent, As I don't have access to little-endian MIPS, In other words my understanding is that *your* MIPS platform is little-endian, isn't it? I noticed something that has to be a bug in sha512-mips.pl, which would fail sha256 test on little-endian MIPS32 platform. Specifically $MSB assignment should read $MSB = $big_endian ? 0 : ($SZ-1); The test *could* have passed, because test is performed on aligned data... Does it make sense to you? A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests
Is libeay32.dll linked with /FIXED? Verify with 'dumpbin /headers libeay32.dll', look for DLL characteristicsNo! The DLL still had the randomization code turned on after I dumped it. It turns out I had the /FIXED flag in the wrong place for the actual DLL. Once I looked closer at the code linking the actual DLL I found the correct place to put the flag. I've now verified the DLL is linked with /FIXED and the libeay32.dll now works for FIPS mode. I tested this on the x86 version of the DLL and I imagine it will fix the x64 DLL as well (they both reported the same error). It looks like this setting will need to be added for VS2010. Thanks to everyone for all of your help! Grant Date: Mon, 18 Oct 2010 21:30:36 +0200 From: ap...@openssl.org To: openssl-dev@openssl.org Subject: Re: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests Question #1. Are we talking about 32-bit version or is it the problem with *both* x86 and x64 code? 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. Define also doesn't work. If I link *both* fips_test_suite.exe *and* libeay.dll with /FIXED (or /DYNAMICBASE:NO), then both fips_test_suite.exe and openssl.exe with OPENSSL_FIPS environment variable set work. With fips_test_suite.exe working, because it itself is linked with /FIXED, and openssl.exe working because libeay32.dll is linked with /FIXED. However, if you link a Visual Studio 2008 generated FIPS canister to a Visual Studio 2010 OpenSSL DLL then everything works. Strange... It's up to linker to set dynamicbase flag in COFF header. Newer compiler must be marking .obj files in some special way, which serves as a message to linker. 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. Originally fipscanister.lib was designed not to have strong dependency on msvcrt, meaning that idea was that it should be possible to use fipscanister compiled with one compiler with another. But it was verified to work with rather old compilers. 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. Is libeay32.dll linked with /FIXED? Verify with 'dumpbin /headers libeay32.dll', look for DLL characteristics. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests
I tested this on the x86 version of the DLL and I imagine it will fix the x64 DLL as well (they both reported the same error). It looks like this setting will need to be added for VS2010. As mentioned [in another reply], I was under impression that x64 code is always position-independent, i.e. I'd expect x64 to work even if relocated. Oh well... Closer look revealed that .text segment, code itself, *is* indeed position-independent, but not .rdata, which is also fingerprinted. In order for this to work it is implied that compiler moves relocatable data from .rdata segment. Unix compiler actually do that, but apparently not Windows:-( A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
sample code for client program to send DTLS alerts to the router
Hello, I need a sample program in C to test DTLS code on my router (server). Or else let me know how can i send DTLS alerts from a windows client to the server. This is very urgent need, Your help is very much appreciated and thanks in advance. Thanks, Ranjith
