| commit | d4396e387c820198f509a6927facea84592cddd8 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Wed Feb 01 15:35:56 2023 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Feb 06 21:12:45 2023 +0000 |
| tree | b9b74b21eee4ab6dca0c0e0978cb508a7cb33945 | |
| parent | d1b451676eada2f2dcad9a20debf8b76fa17f403 [diff] |
Avoid branches in GCC in bn/generic.c. bn/generic.c is used for functions like bn_add_words, when there is no assembly implementation available. They're meant to be constant-time, but are particularly dependent on the compiler in this. I ran our valgrind-based tooling and found a couple issues in GCC: First, the various mul_add and sqr_add macros end up branching in GCC. Replacing the conditionals with expressions like c += (a < b) seems to mitigate this. Second, bn_sub_words produces branches in GCC. Replacing the expressions with bit expressions involving the boolean comparisons seems to work for now. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173 discusses problems with GCC here, which seem to be as yet unresolved. Clang already reliably avoided branches in all of these. (Though it still spills the carry flag far more than would be ideal.) I also checked in godbolt that the new versions didn't generate branches in MSVC, but we don't have tooling to validate this as rigorously. Change-Id: I739758a396fb5ee27fb88bee71bd13ae9cb92bd0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56967 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@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: