The static did_init is incremented _after_ the calls to OpenSSL. This
enlarges the time interval between the test and the set of did_init.
Several threads may slip through this time window and they cause the
segfault when they call the OpenSSL functions concurrently.
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
On 06/10/2015 12:05 PM, [hidden email] wrote:
> I'm getting segfaults when krb5 calls
> openssl_init in pkinit_crypto_openssl.c has the following code:
In 1.13 we switched to doing this in a library initializer, which gets
run only once as long as the PKINIT module isn't unloaded. We also
switched to loading modules with RTLD_NODELETE on platforms which have it.
We could, of course, still race with another thread calling another
library which happens to initialize OpenSSL.
It's also worth noting that we never tear down OpenSSL (because we have
no way of knowing whether the application or another library is still
using it), so all of the heap memory it allocates could get lost if the
PKINIT module and OpenSSL library are unloaded. This shouldn't happen
with 1.13 on platforms with RTLD_NODELETE.
It's kind of a bug in krb5 (even with the 1.13 changes), but it's not a
bug we can currently fix. OpenSSL can't be used safely from a library
in a multithreaded application without help from the calling
application, or without special considerations in the library API (such
as a function the calling application is required to invoke before
spawning any threads).
> It's also worth noting that we never tear down OpenSSL (because we have
> no way of knowing whether the application or another library is still
> using it), so all of the heap memory it allocates could get lost if the
> PKINIT module and OpenSSL library are unloaded. This shouldn't happen
> with 1.13 on platforms with RTLD_NODELETE.
Oh, even for PAM modules where the PAM module and libkrb5 are all
unloaded? That's great news!