|Applies To||RSA BSAFE Crypto-C ME 2.0|
RSA BSAFE Crypto-C ME 2.1
RSA BSAFE SSL-C 2.7
RSA BSAFE MES 2.2
Operating in a multi-threaded environment
|Issue||How to enable thread safety in RSA BSAFE Crypto-C ME, SSL-C and MES|
Intermittant errors, possibly including SSL_ERROR_SYSCALL with SSL-C
Infinite loop when R_lock_num() is called within the locking callback function
|Cause||Proper locking in a multi-threaded environment is not occurring.|
RSA BSAFE Crypto-C ME, SSL-C and MES are not multi-threaded, but they are thread safe as long as the proper locking callbacks are registered and cryptographic objects are not shared between threads. These callbacks provide a method for application programmers to set platform specific locking mechanisms into the BSAFE libraries. When these callbacks are set the libraries will use them to synchronize access to global data structures.
There is a default implementation for the thread ID callback for all release level platforms, so it is unnecessary to implement a callback on these platforms. See the Release Notes for a list of release level platforms. The ability to implement a custom thread ID callback enables developers to use our libraries on non-standard environments and OS's.
In the case of Win32, we'll demonstrate Mutex objects.
In addition to setting up the locking callbacks, the application needs to be written correctly. The external objects are not thread safe ? multiple threads cannot concurrently read and write to a BSAFE object. Normally each thread maintains and accesses its own objects. If multiple threads will be accessing the same object, the application must guarantee they will not access it concurrently.
In order to see exactly where the locking occurs, use the sample callback implementations in your application and define APP_LOCK_TRACE when compiling.
Generally the following operations will perform locking. The most important is the random number generator. Operations are locked for reasons of sharing global entropy. It is possible to use the random number generators without locking but continuous random number generator checks may fail.
R_lock_num() generates a call to the locking callback function, so calling R_lock_num() within a custom locking callback will result in an infinite loop. Generally, you'll want to call R_lock_num() once to determine how many locks to create, before registering the locking callback with R_lock_set_cb(). This is how the default implementations work.
|Legacy Article ID||a33302|