On Wed, Oct 23, 2013 at 08:32:35AM +1000, Peter Waltenberg wrote: > There is no 'safe' way to do this other than hardwired. Admitted, we have a > fairly ugly stack on which to find that out, multiple independently > developed lumps of code jammed into the same process, quite a few using > dlopen()/dlclose() on other libraries - multiples of them calling the > crypto. code.
Oh, good point. I think what I'll do is add targets that denote "always use the OS thread library; disallow setting these callbacks", and a corresponding command-line option to ./config. This should be the best option in general because of the possibility of the text for callbacks being unmapped when the provider gets dlclose()ed. Then maybe there's no need to bother with the pthread_once()/ InitOnceExecuteOnce() business. I had assumed, going in, that I needed to preserve existing semantics as much as possible, but because that might still be the case (even if you're right as to what the ideal should be) I will do *both*. (Who knows, maybe there's a program out there that insists on using the gnu pth library and not the OS' native threading library. Or maybe there's no need to support such oddities.) > All those lumps of code think they 'own' the crypto. stack - worst case > scenario was a dlopen()'d library setting the callbacks, then being > unloaded while other parts of the stack were still using crypto. > Surprisingly - that still worked on some OS's - but some (like AIX/HPUX) > ummap program text immediately on dlclose(). Right. That's a question regarding patch contribution: is it OK to "leak" things that can only really be torn down at dlclose() / unload time and which effectively never happens? "git grep '\.fini\>'" finds nothing in the tree (while "git grep '\.init\>' does), so I'm guessing "yes, it's OK". > Personally, I'd suggest making it build option to turn off default locking > and use whatever the OS provides by default. That'll allow the few corner > cases to continue doing whatever wierd things they were doing before, but > remove the big risk factor for the vast majority of users. And it is > becoming a big risk factor now. > > It certainly shouldn't be an issue for the OS installed OpenSSL which > probably covers most of your users, the only sane choice there is the OS > default locking scheme anyway. Agreed. Thanks for your response, Nico -- ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
