Project

General

Profile

Bug #655

proposed patch to diffie_hellman.c

Added by Noam Lampert over 6 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
libstrongswan
Target version:
Start date:
16.07.2014
Due date:
Estimated time:
Affected version:
5.2.0
Resolution:
Fixed

Description

The attached patch performs thread safe initialization, as opposed to the current initialization which is potentially unsafe, and thread-safety tools (like tsan) tend to complain about.

diffie_hellman.patch (1.85 KB) diffie_hellman.patch Noam Lampert, 16.07.2014 11:56

Associated revisions

Revision 0d927ee2 (diff)
Added by Martin Willi over 6 years ago

diffie-hellman: Explicitly initialize DH exponent sizes during initialization

To avoid any race conditions when multiple threads call and initialize
diffie_hellman_get_params(), explicitly examine the optimum DH exponent size
during library initialization.

Fixes #655.

Revision 7c927d60 (diff)
Added by Martin Willi over 6 years ago

diffie-hellman: Explicitly initialize DH exponent sizes during initialization

To avoid any race conditions when multiple threads call and initialize
diffie_hellman_get_params(), explicitly examine the optimum DH exponent size
during library initialization.

Fixes #655.

Revision 46184b07 (diff)
Added by Martin Willi over 6 years ago

diffie-hellman: Explicitly initialize DH exponent sizes during initialization

To avoid any race conditions when multiple threads call and initialize
diffie_hellman_get_params(), explicitly examine the optimum DH exponent size
during library initialization.

Fixes #655.

History

#1 Updated by Martin Willi over 6 years ago

  • Category set to libstrongswan
  • Status changed from New to Assigned
  • Assignee set to Martin Willi

#2 Updated by Martin Willi over 6 years ago

Noam,

The attached patch performs thread safe initialization, as opposed to the current initialization which is potentially unsafe

Thanks for your patch. I agree, that should be fixed.

Directly relying on <pthread.h> and pthread_once() is not ideal, though. Not all builds use pthreads, on Windows we use native threading primitives.

As we currently have no abstraction for pthread_once functionality (#640), for the time being we probably just should use explicit initialization.

I've pushed the referenced commit, queued for a merge to master.

Regards
Martin

#3 Updated by Noam Lampert over 6 years ago

For reference, pthread_once is used elsewhere in strongswan, so the proposed patch was not introducing a new dependency.

libstrongswan/threading/rwlock.c
libstrongswan/utils/chunk.c
libstrongswan/utils/utils/strerror.c
libfast/fast_request.c

#4 Updated by Martin Willi over 6 years ago

This was true for releases before 5.2.0, but we explicitly removed these dependencies for the Windows support introduced with 5.2.0.

threading/rwlock.c is the pthread implementation of rwlocks, so that doesn't hurt. libfast is a very specific library not used in most builds, and has other Unix dependencies.

Regards
Martin

#5 Updated by Martin Willi over 6 years ago

  • Status changed from Assigned to Closed
  • Resolution set to Fixed

#6 Updated by Martin Willi over 6 years ago

  • Tracker changed from Issue to Bug
  • Target version set to 5.2.1

Also available in: Atom PDF