OpenSSL EVP Latchups
Hello Members, I think what I am going to discuss is an old problem. But I do not know whether there is fix for this problem or not. 1. OpenSSL EVP has OpenSSL_add_all_ type functions, which are not threadsafe. These when called in multi-threaded environment behaves abnormal , some times leads to latchup. 2. It has EVP_cleanup functions which clears all the memory allocated to various hash maps. In multithreaded environment this function maybe called many times. But in Multi-threaded environment, some other application could call init before other freeing it, or many other situations. So, there can be many issues in large processes. I want to know, 1. If some people have applied reference counting solution, does it eliminate this issue?? Or is it safe to write a similar kind of wrapper around OpenSSL. 2. Is there some fix regarding this issue in some higher version (I am using 0.9.8o version). 3. Is this issue still persists? -- Regards, Gaurav
[openssl.org #2953] s_server to show connection duration and transfer speed
Please find attached patch, introducing two new options for s_server: one specify maximum number of connections s_server will accept. It will exit clearly after completing last connection the other tells s_server to show each completed connection duration and data transfer rate. These options exceptionally usable for profiling, debugging and test automation. Patch correctly applied to openssl-1.0.2-stable-SNAP-20130108 In order to apply patch you may use command: patch -p0 -l -u -b -i s_server_limit_show_speed_long.patch and patch -p1 -l -u -b -i s_server_limit_show_speed_doc.patch Please let me know if you have any questions. Andrey. s_server_limit_show_speed_long.patch Description: Binary data s_server_limit_show_speed_doc.patch Description: Binary data
[openssl.org #2954] [PATCH] avoid memcpy for overlapping regions
Using memcpy on overlapping regions of memory is undefined behavior in C. In engines/ccgost/gosthash.c, the circle_xor8() function uses memcpy to copy data between the two arrays passed as arguments, but in some cases (e.g., the third call to circle_xor8 in hash_step() in the same file) the two arguments are identical. Use memmove instead to avoid any problems. Nickolai. --- openssl-1.0.1c/engines/ccgost/gosthash.c2009-12-22 06:52:15.0 -0500 +++ openssl-1.0.1c/engines/ccgost/gosthash.c2013-01-07 15:56:39.716975869 -0500 @@ -42,7 +42,7 @@ byte buf[8]; int i; memcpy(buf,w,8); - memcpy(k,w+8,24); + memmove(k,w+8,24); for(i=0;i8;i++) k[i+24]=buf[i]^k[i]; } __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2952] Testing new RT instance
This is a test of the upgraded RT for openssl.org Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2955] Bug in documentation: s/EVP_PKEY_verifyrecover/EVP_PKEY_verify_recover/
Hi, the documented EVP_PKEY_verifyrecover and EVP_PKEY_verifyrecover_init functions don't exist in 1.0.1c. EVP_PKEY_verify_recover seems to be the right spelling. The following commands should fix the issue: $ sed -i 's/EVP_PKEY_verifyrecover/EVP_PKEY_verify_recover/g' doc/crypto/* $ mv doc/crypto/EVP_PKEY_verifyrecover.pod doc/crypto/EVP_PKEY_verify_recover.pod Kind regards, Martin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2937] Handshake performance degradation in 1.0.1 and up.
On 11 December 2012 04:00, Stephen Henson via RT r...@openssl.org wrote: I also notice that even the original HMAC version initialises two HMAC contexts with the same key. That could be improved by initialising one and copying the context across. This kind of optimization can be also applied P_hash implementation via to EVP_DigestSign*. HMAC contexts being re-initialized in inner loop every time it executed. It is possible to improve it here by initializing only once in the beginning of function, save to some temporary variables, and restore restore from them when needed. It would solve original issue with re-initialilization excessive overhead. BUT: 1. It gives only miserable performance benefits in normal case (i.e. software-only) ( 1%). Hashing of few more bytes is almost nothing in comparison to BN-manipulations. 2. In case of external hardware usage it may lead to the same result: in my case cost of MAC copying call is the same as cost of MAC calculation call. And only way to improve performance is to reduce total amount of remote calls. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2948] thousands of getpid called inside libcrypto.sl.0.9.8
Hi, Thank you. I just notice that the main time consumer is not the getpid(). I also found thousands of “FIPS_selftest_failed” during FIPS mode setup which indeed induce the getpid call. Is it normal that FIPS_mode_set(1) needs 5 seconds to finish? Do you have any idea about the main time consumer here? The call stack is followed. If the self-test has some problem, how should I debug to root cause? Here is the call stack, the following call log just repeated thousands of times in my case. Breakpoint 1, 0x7af3a278 in getpid+0 () from /usr/lib/libc.2 #0 0x7af3a278 in getpid+0 () from /usr/lib/libc.2 #1 0x7a41c454 in CRYPTO_thread_id+0x24 () from libcrypto.sl.0.9.8 #2 0x7a40b5ec in FIPS_selftest_failed+0x6c () from libcrypto.sl.0.9.8 #3 0x7a420764 in EVP_DigestInit_ex+0x34 () from libcrypto.sl.0.9.8 #4 0x7a4251b8 in ssleay_rand_add#HLO_CL_#i1_0x14+0x130 () from libcrypto.sl.0.9.8 #5 0x7a4248e4 in ssleay_rand_bytes+0x1a4 () from libcrypto.sl.0.9.8 #6 0x7a4265b8 in RAND_bytes+0x80 () from libcrypto.sl.0.9.8 #7 0x7a40bd58 in FIPS_mode_set+0x270 () from libcrypto.sl.0.9.8 Breakpoint 1, 0x7af3a278 in getpid+0 () from /usr/lib/libc.2 #0 0x7af3a278 in getpid+0 () from /usr/lib/libc.2 #1 0x7a41c454 in CRYPTO_thread_id+0x24 () from libcrypto.sl.0.9.8 #2 0x7a40b3b0 in FIPS_mode+0x70 () from libcrypto.sl.0.9.8 #3 0x7a420824 in EVP_DigestInit_ex+0xf4 () from libcrypto.sl.0.9.8 #4 0x7a4251b8 in ssleay_rand_add#HLO_CL_#i1_0x14+0x130 () from libcrypto.sl.0.9.8 #5 0x7a4248e4 in ssleay_rand_bytes+0x1a4 () from libcrypto.sl.0.9.8 #6 0x7a4265b8 in RAND_bytes+0x80 () from libcrypto.sl.0.9.8 #7 0x7a40bd58 in FIPS_mode_set+0x270 () from libcrypto.sl.0.9.8 Breakpoint 1, 0x7af3a278 in getpid+0 () from /usr/lib/libc.2 #0 0x7af3a278 in getpid+0 () from /usr/lib/libc.2 #1 0x7a41c454 in CRYPTO_thread_id+0x24 () from libcrypto.sl.0.9.8 #2 0x7a425120 in ssleay_rand_add#HLO_CL_#i1_0x14+0x98 () from libcrypto.sl.0.9.8 #3 0x7a4248e4 in ssleay_rand_bytes+0x1a4 () from libcrypto.sl.0.9.8 #4 0x7a4265b8 in RAND_bytes+0x80 () from libcrypto.sl.0.9.8 #5 0x7a40bd58 in FIPS_mode_set+0x270 () from libcrypto.sl.0.9.8 Breakpoint 1, 0x7af3a278 in getpid+0 () from /usr/lib/libc.2 #0 0x7af3a278 in getpid+0 () from /usr/lib/libc.2 #1 0x7a41c454 in CRYPTO_thread_id+0x24 () from libcrypto.sl.0.9.8 #2 0x7a40b5ec in FIPS_selftest_failed+0x6c () from libcrypto.sl.0.9.8 #3 0x7a420764 in EVP_DigestInit_ex+0x34 () from libcrypto.sl.0.9.8 #4 0x7a4251b8 in ssleay_rand_add#HLO_CL_#i1_0x14+0x130 () from libcrypto.sl.0.9.8 #5 0x7a4248e4 in ssleay_rand_bytes+0x1a4 () from libcrypto.sl.0.9.8 #6 0x7a4265b8 in RAND_bytes+0x80 () from libcrypto.sl.0.9.8 #7 0x7a40bd58 in FIPS_mode_set+0x270 () from libcrypto.sl.0.9.8 Best Regards, -Meiling -Original Message- From: Stephen Henson via RT [mailto:r...@openssl.org] Sent: Thursday, December 27, 2012 6:26 AM To: Ge, Meiling Cc: openssl-dev@openssl.org Subject: [openssl.org #2948] thousands of getpid called inside libcrypto.sl.0.9.8 [meiling...@emc.com - Wed Dec 26 21:07:57 2012]: Hi Openssl team, I have an performance issue with openssl_fips. My application use openssl_fips version 0.9.8. Recently, I found that the fips lib make my application slow. When my application initialize the fips setting, it introduces 7000+ getpid() call. And this will cost 5 seconds. Is this an real issue? Looking forward to your reply. Thanks. The call trace is as followed: Breakpoint 1, 0x7af3a278 in getpid+0 () from /usr/lib/libc.2 #0 0x7af3a278 in getpid+0 () from /usr/lib/libc.2 #1 0x7a41c454 in CRYPTO_thread_id+0x24 () from libcrypto.sl.0.9.8 #2 0x7a40bbd8 in FIPS_mode_set+0xf0 () from libcrypto.sl.0.9.8 #3 0x2695f8 in main+0x168 () These all go through a user settable callback which defaults to getpid() on most platforms. You can supply a more efficient equivalent in an application. 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
Re: [openssl.org #2937] Handshake performance degradation in 1.0.1 and up.
Please find attached two patches, together implementing proper HMAC context re-initialization instead of full re-creation. In comparison to openssl-1.0.1c it gives ~10% handshake performance improvements when some engine-specific MAC are used. In order to apply patches use command patch -p1 -i filename Patches checked to applied to: openssl-1.0.1c openssl-1.0.2-stable-SNAP-20130108 make test report Ok. for both versions (Linux, x86[_64]) Please let me know if you have any questions. TLS_P_hash-HMAC_reinit.patch Description: Binary data TLS_P_hash-HMAC_reinit2.patch Description: Binary data
OpenSSL RT instance migration
Hi, in the process of upgrading and migrating our server infrastructure I have just put the updated Request Tracker into operation. The request tracker stays reachable via r...@openssl.org (or the alias openssl-b...@openssl.org). While the migration is still in progress, the web interface is temporarily available via http[s]://rt.openssl.net/ (please note the .net at the end). Once we have finished updating our infrastructure, the server will move back to openssl.org. Hint: the certificate of the webserver is the openssl.org one so please be prepared for a warning :-) If you are experiencing any problems, please report. Thank you very much for your patience, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2948] thousands of getpid called inside libcrypto.sl.0.9.8
On Thu Jan 10 15:33:12 2013, meiling...@emc.com wrote: Hi, Thank you. I just notice that the main time consumer is not the getpid(). I also found thousands of “FIPS_selftest_failed” during FIPS mode setup which indeed induce the getpid call. Is it normal that FIPS_mode_set(1) needs 5 seconds to finish? For the 1.2 module it can take some time to finish the self tests. One of the requirements for the 2.0 module was to improve the efficiency of the self tests, so that should be much quicker if you can use the 2.0 module. Do you have any idea about the main time consumer here? The call stack is followed. If the self-test has some problem, how should I debug to root cause? The main time consumer is likely to be a call to generate DSA parameters in FIPS_selftest_dsa(). There isn't anything you can do with the 1.2 module to spped that up without changing the source and the result being no longer validated. 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
