[stunnel-users] use of CRYPTO_NUM_LOCKS

[Norm Jacobs]

A while ago, the Solaris security group noticed that stunnel uses 
CRYPTO_NUM_LOCKS to size a lock table in the code at compile time.  They 
noted that there is function CRYPTO_num_locks() that can do the same 
thing at runtime and have requested that the function be used so that 
FIPS/non-FIPS support can be switched on by users simply using 
interposition.  As a result of this, I put together this patch that 
switches to code to use the function instead of macro.

     -Norm

    # stunnel should use CRYPTO_num_locks() function instead of CRYPTO_NUM_LOCKS
    # macro.  The function interogates libcrypto at run-time for sizing and the
    # macro at compile time.  If you interpose a a version at runtime to switch
    # between FIPS/non-FIPS support, the lock table may not be sized correctly.
    #
    diff -r -u stunnel-4.55.orig/src/sthreads.c stunnel-4.55/src/sthreads.c
    --- stunnel-4.55.orig/src/sthreads.c    2012-08-09 14:44:18.000000000 -0700
    +++ stunnel-4.55/src/sthreads.c 2013-03-21 23:29:34.912001586 -0700
    @@ -212,7 +212,7 @@
      #ifdef USE_PTHREAD

      static pthread_mutex_t stunnel_cs[CRIT_SECTIONS];
    -static pthread_mutex_t lock_cs[CRYPTO_NUM_LOCKS];
    +static pthread_mutex_t *lock_cs;

      void enter_critical_section(SECTION_CODE i) {
          pthread_mutex_lock(stunnel_cs+i);
    @@ -275,13 +275,15 @@

      int sthreads_init(void) {
          int i;
    +    int num_locks = CRYPTO_num_locks();

          /* initialize stunnel critical sections */
          for(i=0; i<CRIT_SECTIONS; i++)
              pthread_mutex_init(stunnel_cs+i, NULL);

          /* initialize OpenSSL locking callback */
    -    for(i=0; i<CRYPTO_NUM_LOCKS; i++)
    +    lock_cs = calloc(num_locks, sizeof (*lock_cs));
    +    for(i=0; i<num_locks; i++)
              pthread_mutex_init(lock_cs+i, NULL);
          CRYPTO_set_id_callback(stunnel_thread_id);
          CRYPTO_set_locking_callback(locking_callback);


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130329/b94f8e6c/attachment.html>