Re: Memory Leaks in SSL_Library_init()

2007-03-27 Thread Nitin M
From: Darryl Miles [EMAIL PROTECTED] Reply-To: openssl-dev@openssl.org To: openssl-dev@openssl.org Subject: Re: Memory Leaks in SSL_Library_init() Date: Wed, 21 Mar 2007 11:12:38 + Nitin M wrote: Does this mean that in such scenario the application need not call SSL_library_init since

[Patch] crypto/des/spr.h

2007-03-27 Thread Gisle Vanem
This file lacks a header-guard. It's needed since it is included multiple times in crypto/des/des_opts.c (via des_enc.c). Patch: --- orig/crypto/des/spr.h 2002-03-04 18:01:16 +0100 +++ crypto/des/spr.h2007-03-19 18:32:56 +0100 @@ -56,6 +56,9 @@ * [including the GNU Public Licence.] */

RE: Memory Leaks in SSL_Library_init()

2007-03-27 Thread David Schwartz
1287 void SSL_free_comp_methods(void) 1288 { 1289 if (ssl_comp_methods == NULL) 1290 return; 1291 CRYPTO_w_lock(CRYPTO_LOCK_SSL); 1292 if (ssl_comp_methods != NULL) 1293 { 1294 sk_SSL_COMP_pop_free(ssl_comp_methods,CRYPTO_free);

Re: [PATCH] Mitigation for branch prediction attacks

2007-03-27 Thread Bodo Moeller
On Tue, Mar 27, 2007 at 02:23:08PM -0700, Wood, Matthew D wrote: Changes to OpenSSL 0.9.8d to mitigate branch prediction attacks Thanks! I'm working on moving this into the OpenSSL CVS. I have just one question: In crypto/rsa/rsa_gen.c, you use BN_with_flags() to set BN_FLG_CONSTTIME for d

Re: Memory Leaks in SSL_Library_init()

2007-03-27 Thread Darryl Miles
David Schwartz wrote: 1287 void SSL_free_comp_methods(void) 1288 { 1289 if (ssl_comp_methods == NULL) 1290 return; 1291 CRYPTO_w_lock(CRYPTO_LOCK_SSL); 1292 if (ssl_comp_methods != NULL) 1293 { 1294

Re: Memory Leaks in SSL_Library_init()

2007-03-27 Thread Darryl Miles
Nitin M wrote: I wrote a simple program like this to find out the possibility of a memory leak. The program goes like this. #includeopenssl/ssl.h int main() { SSL_library_init(); EVP_cleanup(); } when I run this programm through the valgrind I get the following output. Ok, it is not

Re: Memory Leaks in SSL_Library_init()

2007-03-27 Thread Nitin M
1 #includeopenssl/ssl.h 2 int main() 3 { 4 SSL_library_init(); 5 6 /* thread-local cleanup */ 7 ERR_remove_state(0); 8 9 /* Globals we finished with */ 10 //

RE: Memory Leaks in SSL_Library_init()

2007-03-27 Thread David Schwartz
For POSIX threads, the result of reading a variable in one thread while it might be modified in another thread is undefined. Line 1289 and 1290 should be removed. Not this old chestnut again. Like it or not, it's a fact. I can't name a CPU in which an aligned load/store of a

Re: Memory Leaks in SSL_Library_init()

2007-03-27 Thread Kyle Hamilton
Oh. I'm sorry. Someone needs to use a keyword 'volatile'. Bingo. Problem solved on the improper optimization issue. Can we commit the patch so that we don't have to keep getting hit by 2 or 3 threads about valgrind complaining about reachable pointers at the end of program execution every

RE: Memory Leaks in SSL_Library_init()

2007-03-27 Thread David Schwartz
Oh. I'm sorry. Someone needs to use a keyword 'volatile'. Sorry, doesn't help. Bingo. Problem solved on the improper optimization issue. What specification says that 'volatile' causes any particular semantics across threads? I must not have read that one. The 'volatile' keyword is only

RE: Memory Leaks in SSL_Library_init()

2007-03-27 Thread Nitin M
So the point you are trying to make is, while the function would solve the purpose of freeing the compression methods, However the lock are not really required in the usage secnario of this function? From: David Schwartz [EMAIL PROTECTED] Reply-To: openssl-dev@openssl.org To: