On Mon, Nov 23, 2015 at 05:28:18PM -0600, Nico Williams wrote:
> It may be a good idea to rethink locking completely.
There is some glimmer of hope in that as various libcrypto structures
become opaque, the locking moves from application code into the
library. For example, we now have (yet to be documented):
X509_up_ref()
function, because applications can no longer directly manipulate
the reference count. For compatibility with older releases Postfix
now defines:
src/tls/tls.h:
#if OPENSSL_VERSION_NUMBER < 0x10100000L
#define X509_up_ref(x) CRYPTO_add(&((x)->references), 1,
CRYPTO_LOCK_X509)
#endif
Mind you, both the old and new interfaces assume that the X509
object (presumably freshly returned by some function) that the
application wants to hang on somewhat longer than default, has not
been deallocated by any other thread in the mean time! So in
particular we are assuming that the caller's thread still "owns"
structures that hold and are responsible for releasing at least
one of the references.
Anyway, with the locking moving into X509_up_ref(), the implementation
moves into the library, where it becomes easier to switch to
fine-grained locking.
We may in more cases need "get1" analogues of existing "get0"
interfaces, so that the user can obtain an already up-refed object
from the library, and just have to call the appropriate "free"
function at the end.
Doing this requires a global review of the API, and filling in
missing functions and documentation. :-(
--
Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
