| commit | e90cf82acc98b899c6ce0334514c38851bc83910 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Mon Dec 27 13:05:36 2021 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Jan 05 19:00:44 2022 +0000 |
| tree | 9c778cfafe8b033b2c6c7ce06d7895d76df33b47 | |
| parent | 9bcc12d540c3b844ba317f042c731d64142af725 [diff] |
Import sha512-armv8.pl transforms from upstream NEON code. We currently have two aarch64 SHA-256 implementations: one using general-purpose registers and one using the SHA-256 extensions. Upstream's 866e505e0d663158b0fe63a7fb7455eebacc6470 added a NEON version. This CL syncs the transforms at the bottom of the file, to avoid potential mistranslations in future imports. It doesn't change the output for our current assembly. Skips the NEON implementation itself for now. It only helps processors without SHA-256 instructions. While Android does not actually mandate the cryptography extensions on ARMv8, most devices have it. Additionally, this file does CPU dispatch in assembly, without taking advantage of static information. We'd end up shipping both fallback SHA-256 implementations. This is particularly silly because NEON is mandatory in ARMv8-A anyway. (Does anyone build us on -R or -M? Probably not?) (If we later have a reason to import it, the binary size cost isn't that significant. Moreover, the NEON fallback is actually slightly smaller than the non-NEON fallback, so if we move CPU dispatch to C, importing may even be worthwhile.) Change-Id: I3c8ca6e77e4e6d1299f975c407cbcf4c9c240523 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50805 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: 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:
There are other files in this directory which might be helpful: