| commit | dd5219451c3ce26221762a15d867edf43b463bb2 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sun Jan 08 18:49:42 2023 -0800 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue May 16 21:55:13 2023 +0000 |
| tree | 2e445a0c1919b0e27e3d38361841b83b935d0f21 | |
| parent | 2eaf07075ac15491c35e1ba1e836797fa81eb96b [diff] |
Fix RAND_enable_fork_unsafe_buffering when called after fork If a process calls fork(), then the child process never forks again, the child may wish to call RAND_enable_fork_unsafe_buffering(). However, doing so exposes a bug: we assume that, if the flag is set, we don't need to worry about fork-safety. But it is possible that the PRNG state was cloned from another process which does not work. Concretely, consider a zygote process, e.g. Chromium's. A zygote process would retain fork-safety, but pass along its PRNG state to each of its children. If the children never fork, they might disable fork-safety, hitting this bug. (Chromium does not call this API. This is just a hypothetical scenario.) Fix this by reseeding whenever the fork-safety bit changes. This fix does not strictly depend on the atomics work, but it causes us to unconditionally sample rand_fork_unsafe_buffering_enabled(). This no longer causes contention because it's just another atomic load. This only affects systems without MADV_WIPEONFORK and without fast RDRAND. If RDRAND is fast, we're always fork-safe and MADV_WIPEONFORK allows us to efficiently detect forks. Cq-Include-Trybots: luci.boringssl.try:linux_clang_rel_tsan Change-Id: I6d0c471c62c951254faf85420a7dc3f4a9d65ee0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59850 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
There are other files in this directory which might be helpful: