RAND_screen() thread safety and RAND_poll() initialization

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RAND_screen() thread safety and RAND_poll() initialization

Tanguy Fautré

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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: RAND_screen() thread safety and RAND_poll() initialization

Goetz Babin-Ebell
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tanguy Fautré wrote:
| 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.

RAND_screen() is part of the OpenSSL initialization code.
All these functions are to be called just once at startup
and MUST NOT be called in a situation where they could be called from
several threads.

Doing that is considered a illegal use of the OpenSSL library and
the usual help you get here is a "fix your initialization code".

Bye

Goetz

- --
DMCA: The greed of the few outweighs the freedom of the many
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKaNDj2iGqZUF3qPYRAuzwAJ9hqukHaiA8YH6jqp58P0zXrN33sgCff24F
q/Jug4R4c/W45/V8S+7doi8=
=SFmo
-----END PGP SIGNATURE-----
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]