| commit | 56d3ad9d23bc130aa9404bfdd1957fe81b3ba498 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sat Jan 27 12:23:29 2024 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Jan 31 22:13:17 2024 +0000 |
| tree | d3789bab037f50e48e63ab069152faee6d418366 | |
| parent | 6855f30b94ddfd2970a7aa3d904a356dea5ec443 [diff] |
Require SSE2 when targetting 32-bit x86 Update-Note: Building for 32-bit x86 may require fixing your builds to pass -msse2 to the compiler. This will also speed up the rest of the code in your project. If your project needs to support the Pentium III, please contact BoringSSL maintainers. As far as I know, all our supported 32-bit x86 consumers require SSE2. I think, in the past, I've asserted that our assembly skips SSE2 capability detection. Looking at it again, I don't think that's true. OPENSSL_IA32_SSE2 means to enable runtime detection of SSE2, not compile-time. Additionally, I don't believe we have *ever* tested the non-SSE2 assembly codepaths. Also, now that we want to take the OPENSSL_ia32cap_P accesses out of assembly, those runtime checks are problematic, as we'd need to bifurcafe functions all the way down to bn_mul_words. Unfortunately, the situation with compilers is... complicated. Ideally, everyone would build with the equivalent of -msse2. 32-bit x86 is so register-poor that running without SSE2 statically available seems especially foolish. However, per https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9868, while Clang defaults to enabling SSE2, GCC does not. We once broke gRPC's build, in https://github.com/grpc/grpc/issues/17540, by inadvertently assuming SSE2. In that discussion, gRPC maintainers were okay requiring Pentium 4 as the minimum CPU, but it's unclear if they actually changed their build. That discussion also said GCC 8 assumes SSE2, but I'm not able to reproduce this. LLVM does indeed interpret "i686" as implying SSE2: https://github.com/llvm/llvm-project/issues/61347 https://github.com/rust-lang/rust/issues/82435 However, Debian LLVM does *not*. Debian carries a patch to turn this off! https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/blob/snapshot/debian/patches/disable-sse2-old-x86.diff?ref_type=heads Meanwhile, Fedora fixed their baseline back in 2018. https://fedoraproject.org/wiki/Changes/Update_i686_architectural_baseline_to_include_SSE2 So let's start by detecting builds that forgot to pass -msse2 and see if we can get them fixed. If this sticks, I'll follow up by unwinding all the SSE2 branches. Bug: 673 Change-Id: I851184b358aaae2926c3e3fe618f3155e71c2f71 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65875 Reviewed-by: Bob Beck <bbe@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: