[openssl-dev] Improving OpenSSL default RNG

[Alessandro Ghedini]

On Fri, Oct 23, 2015 at 05:13:02pm +0000, Salz, Rich wrote:
> > Yes, that's what BoringSSL does. They have three implementations: pthread,
> > windows and none (which is just nops). I don't know what the availability of
> > pthreads is on the above platforms (NW, OS/2 and VMS), but it should cover
> > quite a bit of platforms.
> 
> I'd instead have two:  native or none.  Where hopefully native is mostly
> pthreads, but for NW,OS/2,VMS it can at least start at as none.

Yeah, I guess both pthread and Windows implementations can both be called
"native".

FWIW I did a quick research and NW, OS/2 and VMS all seem to support pthreads
(but I don't know anything about those platforms, so I may be wrong).

> > Basically they deprecated the current CRYPTO_lock and CRYPTO_THREADID
> > API, and replaced that with mutex objects (CRYPTO_MUTEX).
> 
> Not sure about that, I could be persuaded either way, for CRYPTO_lock.  The
> THREADID might need to stay for platform portability.

I think it could be possible to implement CRYPTO_MUTEX and thread-local storage
support by using CRYPTO_lock and CRYPTO_THREADID, so that could be kept as
fallback (e.g. it could be hidden behind OPENSSL_NO_DEPRECATE).

Incidentally a big user of the lock and thread-id API is mem_dbg.c, and looking
at the code in it I was wondering whether we really need it, considering that
now we have better tools to debug memory problems. So at some point I'd like to
try and make OPENSSL_malloc & co. aliases for malloc(), realloc() and free()
and remove (or deprecate) the custom memory functions... but that's probably a
whole different discussion.

> > Additionally,
> > this API provides thread-local storage support and "once" objects (to
> > execute functions only once, for example for initialization).
> 
> I'd probably leave thread-local storage up to the application.

FWIW the ASYNC pull request [0] already uses thread-local storage, but instead
of using the pthread API (which is probably more portable) it uses the __thread
syntax.

The ERR_STATE thing could also be simplified a lot by using thread-local
storage (and the fallback thread-local support can be implemented using
THREADID as it's currently done in ERR_STATE itself, but all the complexity
would be moved to its own file, leaving err.c cleaner).

> But the once stuff would be useful *iff and only iff we used it to make
> initialization simpler.*

The RAND code would be an obvious candidate, but even in BoringSSL once objects
are not used a lot (not that it would add a lot of code since it would be just
a wrapper for pthread_once()).

Cheers

[0] https://github.com/openssl/openssl/pull/433
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20151024/45bf97c7/attachment.sig>