Hi,
Using OpenSSL 0.9.8j via LibCurl 7.19.5, we've discovered some random crashes
and deadlocks that, after further investigations, led us to a call to
RAND_screen() from LibCurl.
Two things puzzles me about the implementation of RAND_screen(), hinting that
it could maybe be a thread safety issue. Hopefully, someone around here can
enlighten me on the situation.
1. RAND_screen() is not protected by locks.
2. RAND_screen() does not check whether RAND_poll() was already called before.
This seems to go against what most functions in OpenSSL do. One of the best
example is ssleay_rand_status() located in crypto/rand/md_rand.c. This function
protects the call to RAND_poll() by locks and ensures RAND_poll() is called
once and only once.
Is RAND_screen() implementation correct? Or should it be protected by locks and
share the initialized global variable in md_rand.c?
I was thinking about maybe replacing
void RAND_screen(void)
{
RAND_poll();
readscreen();
}
by something like
void RAND_screen(void)
{
ssleay_rand_status();
readscreen();
}
which would be quite similar but would rely on the thread safety of
ssleay_rand_status() to call RAND_poll(). Note however that this replacement
will not work as it is because ssleay_rand_status() is declared static in an
other compilation unit.
Cheers,
Tanguy
PS: For the moment, I've worked around the problem by disabling the
RAND_screen() call in LibCurl. Thankfully, LibCurl has a config flag for this.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
