5b33effa72
BoringSSL depends on the platform's locking APIs to make internal global state thread-safe, including the PRNG. On some single-threaded embedded platforms, locking APIs may not exist, so this dependency may be disabled with a build flag. Doing so means the consumer promises the library will never be used in any multi-threaded address space. It causes BoringSSL to be globally thread-unsafe. Setting it inappropriately will subtly and unpredictably corrupt memory and leak secret keys. Unfortunately, folks sometimes misinterpreted OPENSSL_NO_THREADS as skipping an internal thread pool or disabling an optionally extra-thread-safe mode. This is not and has never been the case. Rename it to OPENSSL_NO_THREADS_CORRUPT_MEMORY_AND_LEAK_SECRETS_IF_THREADED to clarify what this option does. Update-Note: As a first step, this CL makes both OPENSSL_NO_THREADS and OPENSSL_NO_THREADS_CORRUPT_MEMORY_AND_LEAK_SECRETS_IF_THREADED work. A later CL will remove the old name, so migrate callers after or at the same time as picking up this CL. Change-Id: Ibe4964ae43eb7a52f08fd966fccb330c0cc11a8c Reviewed-on: https://boringssl-review.googlesource.com/32084 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com> |
||
---|---|---|
.. | ||
internal.h | ||
pool_test.cc | ||
pool.c |