| commit | e68438b863afaa3e81e1771b91819817780f3b60 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Wed Mar 26 17:30:24 2025 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Apr 02 11:51:25 2025 -0700 |
| tree | cb3c54a47ff23d387a5796fd42c34112863fec25 | |
| parent | c86127e656ae8b95622c79ba3d0fb35415502d53 [diff] |
Fix comment on bn_div_rem_words and use MSVC instrinsic We write in the comment that it's a compiler bug that GCC and Clang won't emit the DIV instruction. That dates to https://boringssl-review.googlesource.com/7127, which was an elaborated version of an existing OpenSSL comment: - GNU C generates a call to a function (__udivdi3 to be exact) in reply to ((((BN_ULLONG)n0)<<BN_BITS2)|n1)/d0 (I fail to understand why...); Turns out the compiler is right. If the quotient doesn't fit in a single word, the DIV instruction traps. A truncated BN_ULLONG / BN_ULONG is obligated to output the truncated quotient. (Ideally the compiler would figure it out with bounds on the numerator, but it's hard to figure that out portably and it doesn't seem to figure it out.) Rewrite the comment accordingly. Also, while MSVC doesn't support GCC inline assembly, it has intrinsics for this operation. We may as well use them, since the operation we'd otherwise try to do (BN_ULLONG / BN_ULONG) isn't great anyway. This gives a small speed boost on MSVC. (We use BN_div in computing public BN_MONT_CTX, which is on path to RSA verification.) Not huge, but costs very little. Before: Did 125750 RSA 2048 verify (fresh key) operations in 3015000us (41708.1 ops/sec) After: Did 130250 RSA 2048 verify (fresh key) operations in 3031000us (42972.6 ops/sec) Change-Id: I3e0a9a1ab31d2b9de7bb757837b2d33fc7f81941 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/78147 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> Auto-Submit: David Benjamin <davidben@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:
To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.
There are other files in this directory which might be helpful: