[openssl-dev] Improving OpenSSL default RNG
Alessandro Ghedini
alessandro at ghedini.me
Sat Oct 24 14:22:38 UTC 2015
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>
More information about the openssl-dev
mailing list