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:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Date: Sun, 17 Dec 2000 00:59:19 +0100
From: [EMAIL PROTECTED] (Bodo Moeller)
Cc: [EMAIL PROTECTED] [...]
Subject: Re: cvs commit: openssl/ssl ssl_cert.c ssltest.c
Message-ID: <20001217005919.A889@epsilon>
On Sat, Dec 16, 2000 at 12:31:32AM +0100, Richard Levitte - VMS Whacker wrote:
> levitte> bodo> /* crypto/ex_data.c */
> levitte> bodo> +
> levitte> bodo> +/*
> levitte> bodo> + * This is not thread-safe, nor can it be changed to become
>thread-safe
> levitte> bodo> + * without changing various function prototypes and using a lot of
>locking.
> levitte> bodo> + * Luckily, it's not really used anywhere except in
>ssl_verify_cert_chain
> levitte> bodo> + * via SSL_get_ex_data_X509_STORE_CTX_idx (ssl/ssl_cert.c), where
> levitte> bodo> + * new_func, dup_func, and free_func all are 0.
> levitte> bodo> + *
> levitte> bodo> + * Any multi-threaded application crazy enough to use ex_data for
>its own
> levitte> bodo> + * purposes had better make sure that
>SSL_get_ex_data_X509_STORE_CTX_idx
> levitte> bodo> + * is called once before multiple threads are created.
> levitte> bodo> + */
> levitte>
> levitte> Not quite right. It's also used in the CHIL/hwcrhk engine as a clever
> levitte> tool to keep track of the actual "hardware" key that an RSA is
> levitte> connected to.
> And then I forgot to mention that application have good use of
> ex_data. For example, the verification callback takes only an SSL and
> an integer as arguments. [...]
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).
We could get rid of those global structures by replacing ex_data
stacks by hash tables and moving the new_func, dup_func, and free_func
parameters to CRYPTO_set_ex_data.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--
Bodo Möller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
