RE: OpenSSL 1.1.1g Windows build slow rsa tests
-Original Message- From: openssl-users On Behalf Of Michael Wojcik Sent: Thursday, January 21, 2021 9:28 AM To: openssl-users@openssl.org Subject: RE: OpenSSL 1.1.1g Windows build slow rsa tests > >From: openssl-users On Behalf Of > >Dr Paul Dale > >Sent: Wednesday, 20 January, 2021 19:28 >> >> I'd suggest giving a build without the no-asm option a try. The >> performance difference is usually quite significant. >I agree. It just doesn't explain what Dan's email claims. >> Statis vs dynamic builds wouldn't normally be associated with such a >> large difference. If the difference were routinely this large, nobody >> would use dynamic linking. >In this case it's the static-linked version which is slower. But I'd be >surprised if that's actually the cause. Thank you all for the helpful suggestions. When I removed no-asm and built using nmake in the Developer Command Prompt for Visual Studio 2015, I ended up getting an error "VC-WIN64A X86 conflicts with target x64". From the command prompt I ran cl and saw this "Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86". So I was building for x86? I'm not sure why it built with no-asm, but it did. Once I ran the correct command prompt (I used Visual Studio x64 Native Tools Command Prompt), I saw a huge speed increase. For example, 2048 bits: Doing 2048 bits private rsa's for 10s: 8384 2048 bits private RSA's in 10.02s Doing 2048 bits public rsa's for 10s: 236090 2048 bits public RSA's in 9.98s Previously, I saw: Doing 2048 bits private rsa's for 10s: 409 2048 bits private RSA's in 10.00s Doing 2048 bits public rsa's for 10s: 15663 2048 bits public RSA's in 10.02s For further testing, I added back no-asm and my speed tests were in line with the downloaded openssl binary I was testing with. Doing 2048 bits private rsa's for 10s: 1868 2048 bits private RSA's in 10.00s Doing 2048 bits public rsa's for 10s: 71338 2048 bits public RSA's in 10.02s You can see removing no-asm does make a pretty large speed increase too. In summary, using the correct build tools helps (although I am surprised it built with no-asm). And removing no-asm sped things up.
OpenSSL 1.1.1g Windows build slow rsa tests
Hello, I'm building openssl 1.1.1g on multiple platforms and I found that the rsa speed tests are significantly slower in my build than on the other OS platforms (Linux and macOS). I downloaded a Windows 64-bit binary distribution of openssl from https://kb.firedaemon.com/support/solutions/articles/4000121705 as they include the configure parameters used for their build. I ran the speed rsa tests on their openssl Windows 64-bit binary and they were much faster than the tests on my build. Here's some output. My openssl binary executed with openssl speed rsa: Doing 2048 bits private rsa's for 10s: 409 2048 bits private RSA's in 10.00s Doing 2048 bits public rsa's for 10s: 15663 2048 bits public RSA's in 10.02s Doing 4096 bits private rsa's for 10s: 60 4096 bits private RSA's in 10.00s Doing 4096 bits public rsa's for 10s: 4316 4096 bits public RSA's in 10.02s OpenSSL 1.1.1g 21 Apr 2020 built on: Wed Jan 20 18:38:14 2021 UTC options:bn(64,64) rc4(int) des(long) aes(partial) blowfish(ptr) compiler: cl /Fdossl_static.pdb /Gs0 /GF /Gy /MT /Zi /W3 /wd4090 /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED signverifysign/s verify/s rsa 2048 bits 0.024450s 0.000639s 40.9 1563.9 rsa 4096 bits 0.17s 0.002321s 6.0430.9 Here is the downloaded binary from https://kb.firedaemon.com/support/solutions/articles/4000121705: Doing 2048 bits private rsa's for 10s: 1622 2048 bits private RSA's in 10.02s Doing 2048 bits public rsa's for 10s: 72622 2048 bits public RSA's in 10.00s Doing 4096 bits private rsa's for 10s: 255 4096 bits private RSA's in 10.03s Doing 4096 bits public rsa's for 10s: 18976 4096 bits public RSA's in 10.00s OpenSSL 1.1.1j-dev xx XXX built on: Wed Jan 6 11:11:12 2021 UTC options:bn(64,64) rc4(int) des(long) aes(partial) idea(int) blowfish(ptr) compiler: cl /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED signverifysign/s verify/s rsa 2048 bits 0.006175s 0.000138s161.9 7262.2 rsa 4096 bits 0.039338s 0.000527s 25.4 1897.6 That is a little over 4 times faster. Here are my configure parameters: Configure VC-WIN64A no-shared no-asm no-idea no-mdc2 no-rc5 no-ssl2 no-ssl3 no-zlib no-comp no-pinshared no-ui-console -DOPENSSL_NO_DEPRECATED --api=1.1.0 And their configure parameters: Configure VC-WIN64A no-asm no-ssl3 no-zlib no-comp no-ui-console --api=1.1.0 --prefix="%openssl-dst%" --openssldir=ssl -DOPENSSL_NO_DEPRECATED Both my build and theirs are built with Visual Studio 2015. Any ideas why my build is so much slower? Is there something in my configuration that might cause this?
64-bit 1.1.1e fails to build on macOS 10.8
Hello, I updated from 1.1.1d to the latest version 1.1.1g and had a build error on macOS 10.8 for the 64-bit crypto library. I rolled back to 1.1.1e and reproduced the build error. 32-bit is building fine, only 64-bit has the issue. I looked at the commits for 1.1.1e and nothing jumped out at me. The config parameters are the same between the 64-bit and 32-bit builds other than specific parameters needed to specify the 64-bit build. ./Configure --config=../Patches/openssl/custom_config.conf $os_compiler --prefix=$install_path/openssl_64 -DPURIFY -DOPENSSL_NO_COMP no-shared no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp no-afalgeng no-pinshared no-threads Here is the bottom of the output from the build where the error occurs. It seems like cryptlib.h is not being included for some reason? cc -I. -Iinclude -fPIC -arch x86_64 -O3 -Wall -mmacosx-version-min=10.8 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/Users/csipriuser/Development/ build/third-party/lib/openssl_64/ssl\"" -DENGINESDIR="\"/Users/csipriuser/Development/build/third-party/lib/openssl_64/lib/engines-1.1\"" -DNDEBUG -DPURIFY -DOPENSSL_NO_COMP -MMD -MF crypto/async/arch/async_posix.d.tmp -MT crypto/async/arch/async_posix.o -c -o crypto/async/arch/async_posix.o crypto/async/arch/async_posix.c cc -I. -Iinclude -fPIC -arch x86_64 -O3 -Wall -mmacosx-version-min=10.8 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/Users/csipriuser/Development//build/third-party/lib/openssl_64/ssl\"" -DENGINESDIR="\"/Users/csipriuser/Development/build/third-party/lib/openssl_64/lib/engines-1.1\"" -DNDEBUG -DPURIFY -DOPENSSL_NO_COMP -MMD -MF crypto/async/arch/async_win.d.tmp -MT crypto/async/arch/async_win.o -c -o crypto/async/arch/async_win.o crypto/async/arch/async_win.c cc -I. -Iinclude -fPIC -arch x86_64 -O3 -Wall -mmacosx-version-min=10.8 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/Users/csipriuser/Development//build/third-party/lib/openssl_64/ssl\"" -DENGINESDIR="\"/Users/csipriuser/Development /build/third-party/lib/openssl_64/lib/engines-1.1\"" -DNDEBUG -DPURIFY -DOPENSSL_NO_COMP -MMD -MF crypto/async/async.d.tmp -MT crypto/async/async.o -c -o crypto/async/async.o crypto/async/async.c crypto/async/async.c:37:10: warning: implicit declaration of function 'ossl_init_thread_start' is invalid in C99 [-Wimplicit-function-declaration] if (!ossl_init_thread_start(OPENSSL_INIT_THREAD_ASYNC)) ^ crypto/async/async.c:37:33: error: use of undeclared identifier 'OPENSSL_INIT_THREAD_ASYNC' if (!ossl_init_thread_start(OPENSSL_INIT_THREAD_ASYNC)) ^ crypto/async/async.c:329:33: error: use of undeclared identifier 'OPENSSL_INIT_THREAD_ASYNC' if (!ossl_init_thread_start(OPENSSL_INIT_THREAD_ASYNC)) ^ 1 warning and 2 errors generated. make[1]: *** [crypto/async/async.o] Error 1 make: *** [all] Error 2
RE: Decryption slower in 1.1.1 branch?
Thank you for the information, Victor. >> I upgraded a library that used OpenSSL 1.0.2 to the OpenSSL 1.1.1d. >> On Windows, I have found that the time to decrypt had doubled. After >> a bit of timestamp logging, I found the RSA_private_decrypt function >> is taking twice as long with 1.1.1d as it did with 1.0.2t. This is >> being called from a Windows 64-bit DLL. >RSA is not intended for bulk data decryption, its intended uses are key >transport and signing. Bulk data decryption is done via AES or similar. >> For example, decrypting 8680 bytes of data averages about .3 seconds >> with the OpenSSL 1.0.2t library (statically linked). Decrypting the >> same data with the OpenSSL 1.1.1d library averages about .6 seconds. >Are you sure that's seconds and not milliseconds? These are absurdly long >times, almost certainly dominated by factors other than the encryption >algorithms. On my 2015 laptop (MacOS) I get: Yes, it is seconds. Our library source is cross-platform and I tested on Linux with execution times around 20 milliseconds. This was with a static build rather than shared on Linux. I'm running the Linux tests on a VM on the same machine I am testing the Windows builds. Yet, the Windows build is much slower. Same source code. That's why I initially thought it was something in my OpenSSL configure parameters. While I'm ok with the execution speed with OpenSSL 1.0.2, I'd like to figure out why the times doubled with OpenSSL 1.1.1. I'm logging times before and after the calls to RSA_private_decrypt. With OpenSSL 1.0.2 it takes on average about 4-8 milliseconds for each RSA_private_decrypt call. With OpenSSL 1.1.1d, it takes 10-15 milliseconds for each RSA_private_decrypt call. No code changes other than what was needed such as changing the direct calls to the RSA structure fields. >> I'm wondering if perhaps my build configuration is incorrect or >> missing something for the 1.1.1d build. Here are the configuration >> parameters for the 64-bit build: >There's probably a deeper issue with what you're doing, you need to be much >more specific about what you're measuring. Is this SMIME? CMS? >What is the RSA key size? What is the bulk encryption cipher? The data being decrypted is local on the client machine and is just an XML file. RSA key is 1024 bits. I'm using OAEP padding. > Configure VC-WIN64A --prefix=%RootPath_ThirdParty%\%OPENSSL_VERSION% > -DPURIFY -DOPENSSL_NO_COMP -D_USING_V110_SDK71_ no-shared no-asm > no-idea no-mdc2 no-rc5 no-ssl2 no-ssl3 no-zlib no-comp no-pinshared >PURIFY must not be enabled in production builds, it is only for memory >allocation/safety debugging. You've also disabled assembly optimizations, >which reduces side-channel resistance and hurts performance. Thank you for the information. I removed it from the configuration parameters. I didn't really notice a difference in execution time though. I also removed the no-asm parameter, setup nasm, and rebuilt with no noticeable changes. > I logged things granular enough to see the speed difference was in > RSA_private_decrypt, but I'm not sure why it is so much slower with > 1.1.1d. Any help or ideas would be appreciated! >At 600ms for 8KB, it is not plausible that the time is spend doing >cryptography. That's barely fast enough to feed a 1980's modem. I would expect the execution times to be more in line with what I saw with Linux for both 1.0.2 and 1.1.1. But even so, I do not understand why just upgrading to 1.1.1 causes the RSA_private_decrypt calls to double in execution time from what they were with 1.0.2?
Decryption slower in 1.1.1 branch?
I upgraded a library that used OpenSSL 1.0.2 to the OpenSSL 1.1.1d. On Windows, I have found that the time to decrypt had doubled. After a bit of timestamp logging, I found the RSA_private_decrypt function is taking twice as long with 1.1.1d as it did with 1.0.2t. This is being called from a Windows 64-bit DLL. For example, decrypting 8680 bytes of data averages about .3 seconds with the OpenSSL 1.0.2t library (statically linked). Decrypting the same data with the OpenSSL 1.1.1d library averages about .6 seconds. I'm wondering if perhaps my build configuration is incorrect or missing something for the 1.1.1d build. Here are the configuration parameters for the 64-bit build: Configure VC-WIN64A --prefix=%RootPath_ThirdParty%\%OPENSSL_VERSION% -DPURIFY -DOPENSSL_NO_COMP -D_USING_V110_SDK71_ no-shared no-asm no-idea no-mdc2 no-rc5 no-ssl2 no-ssl3 no-zlib no-comp no-pinshared I logged things granular enough to see the speed difference was in RSA_private_decrypt, but I'm not sure why it is so much slower with 1.1.1d. Any help or ideas would be appreciated!
RE: Linux linking issues moving from 1.0.2t to 1.1.1c
> > > >The no-dso is silently not valid in 1.1.1c. That option didn't work
> > > >right, so it was unusable in practice anyway. However, someone recently
> > > >fixed that up, unfortunately after the last 1.1.1 release.
> > > >The specific patch may be possible to find on github (unless that branch
> > > >has been deleted), otherwise you will have to cherry-pick the
> > > >appropriate commit.
> > >
> > > >Github PR: https://github.com/openssl/openssl/pull/9889
> > > >Commit ID: 8dcd57461972dceaaf014b71d173d0a8758e7054
> > >
> > > >Cheers,
> > > >Richard
> > >
> > > Thanks for the info. I did some more digging and you had actually posted
> > > a workaround in this thread:
> > > https://github.com/openssl/openssl/issues/9036
> > >
> > > I thought I would try it out.
> > > I used your example and created my own config target in file named
> > > no_dos.conf.
> > > (
> > > 'my-linux-x86_64' => {
> > > inherit_from=> [ 'linux-x86_64' ],
> > > dso_scheme => undef,
> > > }
> > > );
> > >
> > > ./Configure --config ../no_dso.conf my-linux-x86_64 -m32
> > > --prefix=$install_path/openssl_32 -DPURIFY -DOPENSSL_NO_COMP no-asm
> > > no-shared no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib
> > > no-comp no-afalgeng no-pinshared
> > >
> > > But I'm getting this error from the script when Configure is run:
> > > target already defined - ../no_dso.conf (offending arg:
> > > my-linux-x86_64)
> > >
> > > What did I miss?
> >
> > You don't happen to have edited some Configurations/*.conf and added
> > that name already? I'm otherwise unsure for the moment.
>
> Figured it out. Configure requires that '--config' be joined to its value
> with an equal sign. In other words, this slight variation
> works:
>
>./Configure --config=../no_dso.conf my-linux-x86_64 -m32
>--prefix=$install_path/openssl_32 -DPURIFY -DOPENSSL_NO_COMP no-asm no-shared
>no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp no-afalgeng
>no-pinshared
>
Thank you! That seems to have fixed things up nicely, and I no longer need to
link libdl when linking my library.
Another question is why I now need to link pthreads when I did not in the 1.0.2
version? I've added no-threads to the configuration, but I'm curious why I
didn't need to previously link it. And I'd prefer not to change too many
configuration parameters if possible.
RE: Linux linking issues moving from 1.0.2t to 1.1.1c
>The no-dso is silently not valid in 1.1.1c. That option didn't work right, so
>it was unusable in practice anyway. However, someone recently fixed that up,
>unfortunately after the last 1.1.1 release.
>The specific patch may be possible to find on github (unless that branch has
>been deleted), otherwise you will have to cherry-pick the appropriate commit.
>Github PR: https://github.com/openssl/openssl/pull/9889
>Commit ID: 8dcd57461972dceaaf014b71d173d0a8758e7054
>Cheers,
>Richard
Thanks for the info. I did some more digging and you had actually posted a
workaround in this thread:
https://github.com/openssl/openssl/issues/9036
I thought I would try it out.
I used your example and created my own config target in file named no_dos.conf.
(
'my-linux-x86_64' => {
inherit_from=> [ 'linux-x86_64' ],
dso_scheme => undef,
}
);
./Configure --config ../no_dso.conf my-linux-x86_64 -m32
--prefix=$install_path/openssl_32 -DPURIFY -DOPENSSL_NO_COMP no-asm no-shared
no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp no-afalgeng
no-pinshared
But I'm getting this error from the script when Configure is run:
target already defined - ../no_dso.conf (offending arg: my-linux-x86_64)
What did I miss?
Linux linking issues moving from 1.0.2t to 1.1.1c
Please bear with me as I am a Windows developer, and not too adept with Linux. Our library has been using the OpenSSL 1.0.2x branch, and we are moving to 1.1.1c. I have the Windows build of our libraries working, and now I've moved to Linux. Our library is built as a shared library as well as static library and both use the static OpenSSL library (we archive the OpenSSL static library with our static library). When I built our shared library I had some linker errors: e/Debug32/mylib.so: undefined reference to `dlopen' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_rwlock_rdlock' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_rwlock_init' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_getspecific' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_rwlock_destroy' ../../MyLib/Debug32/libMyLib.so: undefined reference to `dlclose' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_key_create' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_rwlock_wrlock' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_once' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_atfork' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_setspecific' ../../MyLib/Debug32/libMyLib.so: undefined reference to `dlerror' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_rwlock_unlock' ../../MyLib/Debug32/libMyLib.so: undefined reference to `dlsym' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_key_delete' ../../MyLib/Debug32/libMyLib.so: undefined reference to `dladdr' And the Configuration line from our build script: ./Configure linux-x86_64 --prefix=$install_path/openssl_64 -DPURIFY -DOPENSSL_NO_COMP no-shared no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp no-afalgeng no-pinshared As our library does not use multiple threads, I can build the OpenSSL library with the no-threads configuration parameter to remove the pthread references. Is there anything I should be aware of when doing so? For the dlopen, dlclose, dlerror,dlsym, and dladdr references, it seems I need to link libld using -ldl. Isn't the no-dso configuration option supposed to remove the need for this library? Is there a way to do so with 1.1.1c? While I can link this in our shared library, our static library will require anyone using our library to link libld. I'd like to avoid this if possible, and it seems we could with the 1.0.2 branch. Am I missing something here? Thanks in advance!
RE: OPENSSL_init_crypto with OPENSSL_INIT_NO_ATEXIT issue
>The output certainly suggests something is calling TlsAlloc between the call
>made for destructor_key.value and the one for private_drbg, and that index is
>never freed. You always get 7 when allocating destructor_key.value because
>that >index was freed when you unloaded OpenSSL, and so it's the next
>available one when you load OpenSSL again.
>
>It may not be OpenSSL itself that's calling TlsAlloc and not releasing an
>index - it may be one of its dependencies.
>
>Have you duplicated this under a debugger, with a breakpoint on TlsAlloc? The
>earlier messages suggest that you may have, but it's not entirely clear from
>what you posted. You ought to be able to catch the offending call and get at
>>least a partial traceback.
>
>If you're having trouble tracing it, you could try adding this:
>
>{int i; for (i=8; i
>right after the code that calls TlsAlloc for private_drbg, and seeing what
>blows up. Not entirely conventional, but it might be revealing.
After some further debugging, it appears there is an unknown TSAlloc called
which returned index 8. OpenSSL was allocating index 7, then the index 8 was
allocated somewhere outside the OpenSSL library, and finally OpenSSL allocated
indexes 9, 10, and 11. I was able to call TlsFree(8) in my DLLMain when my DLL
is unloaded and I didn't have any more issues. Obviously, that is not a fix
and I was further able to track down at least where the allocation was
happening. It is actually in a call to libxml2 and does not appear to be
related to OpenSSL. Now I just need to figure out why libxml2 is not freeing
it.
Thank you Matt and Michael for you help. :-)
RE: OPENSSL_init_crypto with OPENSSL_INIT_NO_ATEXIT issue
On 09/08/2019 14:33, Dan Heinz wrote: >> I have a static library using OpenSSL (built as static library with >> the no-pinshared parameter in the configuration) that is then included >> in a DLL that gets loaded and unloaded many times by the calling >> application. Now that the code is in 1.1.1c to allow me to manually >> shutdown the OpenSSL library, I've run into an issue when loading and >> unloading my DLL multiple times from the calling application. I am testing >> this on Windows 10. A summary of what I am doing: >> >> 1. Calling executable calls LoadLibrary to load the DLL containing the >> static >> library that uses OpenSSL. >> 2. Calling executable calls a function of the now loaded DLL. >> 3. The DLL function calls a function in the static library to initialize >> OpenSSL using: openssl_result = >> OPENSSL_init_crypto(OPENSSL_INIT_NO_ATEXIT, >> NULL); >> 4. The DLL function calls a function in the static library to decrypt some >> data >> using the RSA_private_decrypt OpenSSL API. >> 5. The DLL function calls a function in the static library to shutdown >> OpenSSL >> using: OPENSSL_cleanup(); (required) and CRYPTO_cleanup_all_ex_data(); >> (not >> sure if this is needed). >> 6. The calling executable uses FreeLibrary to unload the DLL. >> 7. The calling executable goes to step 1 to repeat the process. >> >> Iterating through the above steps always fails on iteration 1077. >> OpenSLL reports the error: >> error:4088003:rsa routines:RSA_setup_binding:BN lib >> >> >> >> After some debugging, I see that the failure happens in the function >> CRYPTO_THREAD_init_local in threads_win.c. *key = TlsAlloc(); fails >> with the error TLS_OUT_OF_INDEXES. >> >> Is something not being freed? Is there something additional I need to >> do at shutdown? >For every call of CRYPTO_THREAD_init_local() while the library is running you >should see a matching call to CRYPTO_THREAD_cleanup_local() to cleanup the >index (as a result of an OPENSSL_cleanup() call). If you don't see that then >an >index is leaking. Thanks for the guidance, Matt. I added some code to output the counts of the calls to TlsAlloc and TlsFree. I see 4 allocations and 4 matching deallocations for each iteration of my tests. The allocations/deallocations are for: destructor_key.value in OPENSSL_cleanup() private_drbg(from CRYPTO_THREAD_init_local(&private_drbg, NULL)) public_drbg (from CRYPTO_THREAD_init_local(&public_drbg, NULL)) err_thread_local(fromCRYPTO_THREAD_init_local(&err_thread_local, NULL)) On the 1076th test iteration, I get the error (TLS_OUT_OF_INDEXES) from TlsAlloc. I checked for any errors from TlsFree during the tests and it always returns success. One thing I did notice is that the index value (from this line: *key = TlsAlloc()) is always incremented by 1 after each test iteration. The destructor_key.value always stayed the same number (7), but the other three allocations always incremented the value of the key variable. By the time my test reaches the 1076th iteration, the value of key is just under 2000. For example the indices from TlsAlloc might be 10,11, and 12 and the next iteration they are 11, 12, 13. MS documentation states "The maximum number of indexes per process is 1,088" which seems to coincide with the number of my test iterations. None of my code uses thread local storage. Any ideas? Here's some output from my tests (note the key values keep incrementing). Iteration: 1*** Key value: 7 TlsAlloc called. AllocationCount: 1 Key value: 9 TlsAlloc called. AllocationCount: 2 Key value: 10 TlsAlloc called. AllocationCount: 3 Key value: 11 TlsAlloc called. AllocationCount: 4 TlsFree called. AllocationCount: 3 TlsFree called. AllocationCount: 2 TlsFree called. AllocationCount: 1 TlsFree called. AllocationCount: 0 Iteration: 2*** Key value: 7 TlsAlloc called. AllocationCount: 1 Key value: 10 TlsAlloc called. AllocationCount: 2 Key value: 11 TlsAlloc called. AllocationCount: 3 Key value: 12 TlsAlloc called. AllocationCount: 4 TlsFree called. AllocationCount: 3 TlsFree called. AllocationCount: 2 TlsFree called. AllocationCount: 1 TlsFree called. AllocationCount: 0 . Iteration: 1076*** Key value: 7 TlsAlloc called. AllocationCount: 1 Key value: 1086 TlsAlloc called. AllocationCount: 2 Key value: 1087 TlsAlloc called. AllocationCount: 3 Key value: 4294967295 (this is TLS_OUT_OF_INDEXES)
OPENSSL_init_crypto with OPENSSL_INIT_NO_ATEXIT issue
I have a static library using OpenSSL (built as static library with the no-pinshared parameter in the configuration) that is then included in a DLL that gets loaded and unloaded many times by the calling application. Now that the code is in 1.1.1c to allow me to manually shutdown the OpenSSL library, I've run into an issue when loading and unloading my DLL multiple times from the calling application. I am testing this on Windows 10. A summary of what I am doing: 1. Calling executable calls LoadLibrary to load the DLL containing the static library that uses OpenSSL. 2. Calling executable calls a function of the now loaded DLL. 3. The DLL function calls a function in the static library to initialize OpenSSL using: openssl_result = OPENSSL_init_crypto(OPENSSL_INIT_NO_ATEXIT, NULL); 4. The DLL function calls a function in the static library to decrypt some data using the RSA_private_decrypt OpenSSL API. 5. The DLL function calls a function in the static library to shutdown OpenSSL using: OPENSSL_cleanup(); (required) and CRYPTO_cleanup_all_ex_data(); (not sure if this is needed). 6. The calling executable uses FreeLibrary to unload the DLL. 7. The calling executable goes to step 1 to repeat the process. Iterating through the above steps always fails on iteration 1077. OpenSLL reports the error: error:4088003:rsa routines:RSA_setup_binding:BN lib After some debugging, I see that the failure happens in the function CRYPTO_THREAD_init_local in threads_win.c. *key = TlsAlloc(); fails with the error TLS_OUT_OF_INDEXES. Is something not being freed? Is there something additional I need to do at shutdown?
[openssl-users] Manual Shutdown of OpenSSL 1.1.x library
Is there currently a way to manually shutdown the OpenSSL library? We have a DLL that statically links OpenSSL. Our DLL gets loaded and unloaded multiple times by a process (not our process), and we need to release OpenSSL each time. This was not possible with OpenSSL 1.1 as of September 2017 as the process's atexit is where it gets released which will not be called after a FreeLibrary() call on our DLL. Has this been revisited? If there now a way to manually release OpenSSL, or are there any plans to add this ability? Here is a link to our original post and discussion from January 2017: https://www.mail-archive.com/openssl-users@openssl.org/msg80781.html >From the previous post, something like this would address the issue: "I'm >wondering whether an option to override the default behavior might be >possible, e.g. an explicit call to OPENSSL_init_crypto() with something like >an OPENSSL_INIT_NO_ATEXIT_CLEANUP option. The application would then have to >call OPENSSL_cleanup() explicitly." -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Manual Shutdown of OpenSSL 1.1.x library
We have not moved from OpenSSL 1.0.x to OpenSSL 1.1.x as we require the ability to manually shutdown the library. We noticed in the latest release notes the following: "Modify compression code so it frees up structures without using the ex_data callbacks. This works around a problem where some applications call CRYPTO_cleanup_all_ex_data() before application exit (e.g. when restarting) then use compression (e.g. SSL with compression) later. This results in significant per-connection memory leaks and has caused some security issues including CVE-2008-1678 and CVE-2009-4355". Is there now a way to manually shutdown the library? To summarize: We have a DLL that statically links OpenSSL. Our DLL gets loaded and unloaded multiple times by a process (not our process), and we need to release OpenSSL each time. This was not possible with OpenSSL 1.1 as of September 2017 as the process's atexit is where it gets released which will not be called after a FreeLibrary() call on our DLL. Has this been revisited? If there now a way to manually release OpenSSL, or are there any plans to add this ability? >From the previous post, something like this would address the issue: "I'm >wondering whether an option to override the default behavior might be >possible, e.g. an explicit call to OPENSSL_init_crypto() with something like >an OPENSSL_INIT_NO_ATEXIT_CLEANUP option. The application would then have to >call OPENSSL_cleanup() explicitly." Original issue posted with discussion: https://www.mail-archive.com/openssl-users@openssl.org/msg80781.html -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Manually shutdown the library
The original issue was discussed here: https://www.mail-archive.com/openssl-users@openssl.org/msg80781.html To summarize: We have a DLL that statically links OpenSSL. Our DLL gets loaded and unloaded multiple times by a process (not our process), and we need to release OpenSSL each time. This was not possible with OpenSSL 1.1 as of October 2016 as the process's atexit is where it gets released which will not be called after a FreeLibrary() call on our DLL. Has this been revisited? If there is still not a way to manually release OpenSSL, are there any plans to add this ability? >From the previous post, something like this would address the issue: "I'm wondering whether an option to override the default behaviour might be possible, e.g. an explicit call to OPENSSL_init_crypto() with something like an OPENSSL_INIT_NO_ATEXIT_CLEANUP option. The application would then have to call OPENSSL_cleanup() explicitly." -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Openssl static build linked in DLL does not unload on win32
>>>> On 04/01/17 23:11, Dan Heinz wrote: Using openssl 1.1.0c. >>>> >>>> I have a test application that is a win32 console app that calls a > >>> win32 DLL which has the openssl libraries linked in statically>. >>>> >>>> The test applications uses late-binding to the DLL and calls >>>> LoadLibrary for the DLL, one test function in the DLL, and then >>>> FreeLibrary on the DLL.> >>>> >>>> >>>> >>>> The test function in the DLL does the following:> >>>> >>>> RSA*rsa = NULL; >>>> >>>> rsa = RSA_new();> >>>> >>>> RSA_free(rsa); >>>> >>>> OPENSSL_thread_stop();> >>>> >>>> OPENSSL_cleanup(); >>>> >>>> return0;> >>>> >>>> When FreeLibrary is called on the DLL, dllmain in never called with >>>> any messages. A subsequent call to LoadLibrary also fails to call >>>> dllmain and when the test function is called RSA_new() fails. This > >>> leads me to believe the DLL is never freed>. >>>> >>>> I have tried building openssl with and without no-threads with the >>>> same results. My build parameters are: perl Configure >>>> *%TEMP_ARCHITECTURE%*> >>> --prefix=*%RootPath_T>hirdParty%*\*%OPENSSL_VERSION%* -DPURIFY >>> -DOPENSSL_NO_COMP -D>_USING_V110_SDK71_ no-shared no-threads no-asm >>> no-idea no-mdc2 no->rc5 no-ssl3 no-zlib no-comp >>>> >>>> What am I missing? >>> >>> > >> >OpenSSL does its cleanup at *process* exit. Don't call >>> OPENSSL_cleanup() explicitly - this is >discouraged. >>> >>> From this manpage:> >>> >>> https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_init_crypto.html >>>> >>>> >>>> "Ty>pically there should be no need to call this function directly as it is initiated >a>utomatically on application exit.. >>> >>> Once OPENSSL_cleanup() has been called the library cannot be > >>> reinitialised.>" >>> >>> This last sentence is the reason why RSA_new() will fail after you >>> have previously called >OPENSSL_cleanup().> >>> >>> Because cleanup happens on process exit, OpenSSL will keep itself in >>> memory until that time >(otherwise crashes will occur because the > >>> cleanup routines have been unloaded)>. >>> >>> If you want to dynamically load and unload your DLL then don't >>> statically link it to OpenSSL - >otherwise OpenSSL will keep your DLL > >>> around until process exit too>. >>> >>> Matt >>> >>That is very disappointing. As a library vendor we have no control >> over how our users load and unload our libraries. We will just have >> to roll back to 1.0.x and wait to see if this will be addressed. >> Also, as Jakob stated in another post, it really seems like this >> design will be problematic. > >Can you not link against the OpenSSL DLLs rather than statically link? >That would avoid the problem. Unfortunately, no. We need to control the version of OpenSSL, and our users generally do not wish to have to distribute another DLL. In addition, the static link adds a bit more protection from tampering. I see you posted a link elsewhere to the discussion regarding this decision and I will examine it. Being able to explicitly initialize and exit the library would certainly fix the issue for us and most likely others who will run into this same issue. Thanks, Dan -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Openssl static build linked in DLL does not unload on win32
>>On 04/01/17 23:11, Dan Heinz wrote: >> Using openssl 1.1.0c. >> >> I have a test application that is a win32 console app that calls a >> win32 DLL which has the openssl libraries linked in statically. >> >> The test applications uses late-binding to the DLL and calls >> LoadLibrary for the DLL, one test function in the DLL, and then FreeLibrary >> on the DLL. >> >> >> >> The test function in the DLL does the following: >> >> RSA*rsa = NULL; >> >> rsa = RSA_new(); >> >> RSA_free(rsa); >> >> OPENSSL_thread_stop(); >> >> OPENSSL_cleanup(); >> >> return0; >> >> When FreeLibrary is called on the DLL, dllmain in never called with >> any messages. A subsequent call to LoadLibrary also fails to call >> dllmain and when the test function is called RSA_new() fails. This >> leads me to believe the DLL is never freed. >> >> I have tried building openssl with and without no-threads with the >> same results. My build parameters are: >> perl Configure *%TEMP_ARCHITECTURE%* >> --prefix=*%RootPath_ThirdParty%*\*%OPENSSL_VERSION%* -DPURIFY >> -DOPENSSL_NO_COMP -D_USING_V110_SDK71_ no-shared no-threads no-asm >> no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp >> >> What am I missing? > > >OpenSSL does its cleanup at *process* exit. Don't call OPENSSL_cleanup() >explicitly - this is >discouraged. > >From this manpage: > >https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_init_crypto.html > >"Typically there should be no need to call this function directly as it is >initiated >automatically on application exit.. > >Once OPENSSL_cleanup() has been called the library cannot be reinitialised." > >This last sentence is the reason why RSA_new() will fail after you have >previously called >OPENSSL_cleanup(). > >Because cleanup happens on process exit, OpenSSL will keep itself in memory >until that time >(otherwise crashes will occur because the cleanup routines >have been unloaded). > >If you want to dynamically load and unload your DLL then don't statically link >it to OpenSSL - >otherwise OpenSSL will keep your DLL around until process >exit too. > >Matt That is very disappointing. As a library vendor we have no control over how our users load and unload our libraries. We will just have to roll back to 1.0.x and wait to see if this will be addressed. Also, as Jakob stated in another post, it really seems like this design will be problematic. Thanks, Dan -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Openssl static build linked in DLL does not unload on win32
Using openssl 1.1.0c. I have a test application that is a win32 console app that calls a win32 DLL which has the openssl libraries linked in statically. The test applications uses late-binding to the DLL and calls LoadLibrary for the DLL, one test function in the DLL, and then FreeLibrary on the DLL. The test function in the DLL does the following: RSA *rsa = NULL; rsa = RSA_new(); RSA_free(rsa); OPENSSL_thread_stop(); OPENSSL_cleanup(); return 0; When FreeLibrary is called on the DLL, dllmain in never called with any messages. A subsequent call to LoadLibrary also fails to call dllmain and when the test function is called RSA_new() fails. This leads me to believe the DLL is never freed. I have tried building openssl with and without no-threads with the same results. My build parameters are: perl Configure %TEMP_ARCHITECTURE% --prefix=%RootPath_ThirdParty%\%OPENSSL_VERSION% -DPURIFY -DOPENSSL_NO_COMP -D_USING_V110_SDK71_ no-shared no-threads no-asm no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp What am I missing? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
