Bodo Moeller wrote:
>
> On Wed, Jan 10, 2001 at 06:11:57PM +0000, Dr S N Henson wrote:
> > [EMAIL PROTECTED] wrote:
>
> >> + o crypto/ex_data.c is not really thread-safe and so must be used
> >> + with care (e.g., extra locking where necessary, or don't call
> >> + CRYPTO_get_ex_new_index once multiple threads exist).
> >> + The current API is not suitable for everything that it pretends
> >> + to offer.
>
> > Can you expand on this so we can decide what to do about it?
>
> There has already been some discussion on this; see follow-ups to my
> commits in ex_data.c, e.g. this message:
>
Yes I saw those I wondered if you saw any other issues?
>
> Of course you need *some* way to add application-defined data to about
> everything, but it definitely should not look like ex_data.c.
> If all flavours of extra pointers (the ex_data indexes with their
> associated new_funcs, dup_funcs, and free_funcs) were always allocated
> at application initialization before additional threads are spawned,
> then everything should be well; but this is not how ssl/ssl_cert.c
> works. Unless we declare that ssl_cert.c is wrong to use ex_data in a
> possibly multi-threaded environment, we have to blame ex_data.c for
> using global data structures (ex_data "meth"s) in an inappropriate
> way, and also overusing them in that concurrency would be severely
> limited because of the locking requirements if ex_data.c were made
> thread-safe (dynlocks can't help here because the "meth"s are global).
>
So we give the advice that applications should call the
get_ex_new_index() before starting any threads. In this regard ex_data
is no worse than other things such as the object or algorithm tables
which can get in a mess if applications start adding the same object or
algorithm in multiple threads.
Now ssl/ssl_cert.c does indeed have to do something different because it
can have problems if it is called in multiple threads. It isn't quite as
bad as it initially seemed because SSL_get_ex_data_X509_STORE_CTX_idx()
is also called in SSL_CTX_new() see ssl_lib.c . If an application
creates a single SSL_CTX before starting threads (as many do) then this
shouldn't have been a problem.
We can't however rule out an application creating multiple SSL_CTX
structures in multiple threads so it does need the locking fix.
That by itself doesn't violate the advice since we're saying
applications shouldn't call get_ex_new_index() in multiple threads and
often have to do things applications shouldn't in the library itself.
So with that qualification about use of ex_data placed in a prominent
place in the docs are there any other problems?
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
