| commit | 676a8022db7bd707fcb201a13203686222494cbc | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sun Dec 15 15:44:34 2024 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Sun Dec 15 14:03:57 2024 -0800 |
| tree | 259a62e2df12e87386b04cfc1ab6fcb137e5325c | |
| parent | 9e65c3e4d5f8f6bc3074d362d14ce5801a61ad24 [diff] |
Remove alignment requirement on ghash-ssse3 https://boringssl-review.googlesource.com/c/boringssl/+/74268 broke the SSSE3 GHASH fallback because it no longer maintained alignment of Htable. We had been relying on the memcpy to copy Htable into something aligned. Maintaining the alignment requirement without the memcpy is kind of a nuisance because it now leaks into EVP_AEAD_CTX. Since we don't have a good way to make caller-allocatable structs aligned, it would mean allocating 15 extra bytes and then finding the right position. Benchmarks shows that the alignment makes no difference on a Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz. Of course, this is artificial because that CPU would never run this code anyway. I recall adding the alignment requirement because it gave a bit of a perf boost on the old Mac Mini 2010 I was testing against, which actually is a CPU that would run it. I was able to dig it up, but apparently I no longer have a keyboard that's compatible with it. (That machine is also long EOL and cannot even run Chrome's minimum macOS version. Although its CPU may be representative for older Windows.) Regardless, I don't think it makes sense to expend this complexity for this. (See internal Chrome UMA Net.QuicSession.PreferAesGcm on Windows for the percentage of Windows that would be running this code. Though they should also be using ChaCha20-Poly1305 anyway.) Bug: 42290477 Change-Id: I4ef8c636bfc18200869f011ea50cc5d4988244ba Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74327 Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: 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:
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: