NIST publishes the PDFs of the security policy documents (although the
latest one is still missing). We include the docx sources to help others
who might be doing a rebrand certification of BoringCrypto.
Change-Id: I5c1511d53ec1d09d257d3aab1301486c364b660b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51505
Reviewed-by: David Benjamin <davidben@google.com>
On Arm, our CRYPTO_is_*_capable functions check the corresponding
preprocessor symbol. This allows us to automatically drop dynamic checks
and fallback code when some capability is always avilable.
This CL does the same on x86, as well as consolidates our
OPENSSL_ia32cap_P checks in one place. Since this abstraction is
incompatible with some optimizations we do around OPENSSL_ia32cap_get()
in the FIPS module, I've marked the symbol __attribute__((const)), which
is enough to make GCC and Clang do the optimizations for us. (We already
do the same to DEFINE_BSS_GET.)
Most x86 platforms support a much wider range of capabilities, so this
is usually a no-op. But, notably, all x86_64 Mac hardware has SSSE3
available, so this allows us to statically drop an AES implementation.
(On macOS with -Wl,-dead_strip, this seems to trim 35080 bytes from the
bssl binary.) Configs like -march=native can also drop a bunch of code.
Update-Note: This CL may break build environments that incorrectly mark
some instruction as statically available. This is unlikely to happen
with vector instructions like AVX, where the compiler could freely emit
them anyway. However, instructions like AES-NI might be set incorrectly.
Change-Id: I44fd715c9887d3fda7cb4519c03bee4d4f2c7ea6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51548
Reviewed-by: Adam Langley <agl@google.com>
x86_64-mont5.pl checks for both BMI1 and BMI2, because the MULX path
also uses the ANDN instruction. Some history here from upstream:
a5bb5bca52f57021a4017521c55a6b3590bbba7a, dated 2013-10-03, added the
MULX path to x86_64-mont5.pl. At the time, the cpuid check was
BMI2+ADX. (MULX comes from BMI2.)
37de2b5c1e370b493932552556940eb89922b027, dated 2013-10-09, made
BN_mod_exp_mont_consttime prefer the MULX mont5 code over the AVX2 rsaz
code, with a matching BMI2+ADX cpuid check.
8fc8f486f7fa098c9fbb6a6ae399e3c6856e0d87, dated 2016-01-25, tweaked some
code to use the ANDN instruction, from BMI1. Correspondingly, it changed
the cpuid check to be BMI1+BMI2+ADX. The BN_mod_exp_mont_consttime check
was left unchanged.
This CL fixes our version of the BN_mod_exp_mont_consttime check to
match the assembly, by also checking BMI1. (This should be a no-op.
Presumably any processor with BMI2 also has BMI1.)
Change-Id: Ib0cacc7e2be840d970460eef4dd9ded7fb24231c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51547
Reviewed-by: Adam Langley <agl@google.com>
While our CI machines don't have these instructions, Intel SDE covers
them. Benchmarks on an AMD EPYC machine (VM on Google Compute Engine):
Before:
Did 13619000 SHA-256 (16 bytes) operations in 3000147us (72.6 MB/sec)
Did 3728000 SHA-256 (256 bytes) operations in 3000566us (318.1 MB/sec)
Did 920000 SHA-256 (1350 bytes) operations in 3002829us (413.6 MB/sec)
Did 161000 SHA-256 (8192 bytes) operations in 3017473us (437.1 MB/sec)
Did 81000 SHA-256 (16384 bytes) operations in 3029284us (438.1 MB/sec)
After:
Did 25442000 SHA-256 (16 bytes) operations in 3000010us (135.7 MB/sec) [+86.8%]
Did 10706000 SHA-256 (256 bytes) operations in 3000171us (913.5 MB/sec) [+187.2%]
Did 3119000 SHA-256 (1350 bytes) operations in 3000470us (1403.3 MB/sec) [+239.3%]
Did 572000 SHA-256 (8192 bytes) operations in 3001226us (1561.3 MB/sec) [+257.2%]
Did 289000 SHA-256 (16384 bytes) operations in 3006936us (1574.7 MB/sec) [+259.4%]
Although we don't currently have unwind tests in CI, I ran the unwind
tests manually on the same VM. They pass, after adding in the missing
.cfi_startproc and .cfi_endproc lines.
Change-Id: I45b91819e7dcc31e63813843129afa146d0c9d47
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51546
Reviewed-by: Adam Langley <agl@google.com>
macOS requires an explicit EKU extension. This fixes connection failing
with ERR_CERT_INVALID in Chrome (when the built-in verifier isn't
enabled).
https://support.apple.com/en-us/HT210176
Change-Id: Ida23391107fe0168a854c1f4ea3ac52db670e7e8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51525
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
fips_break_test.h is a bad name because generate_build_files.py thinks
that it's a test file, which it is, but one that's needed in the main
build. Thanks to Svilen Kanev for noting this.
That header doesn't particularly carry its weight. The idea was that
rebuilding the break test wouldn't need to rebuild everything if that
logic was isolated in its own header. But we only have to rebuild once
now, so whatever. There's already a block of crypto/internal.h with very
similar stuff; it can go there.
Change-Id: Ifb479eafd4df9a7aac4804cae06ba87257c77fc3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51485
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Change-Id: I6dabeb0a9090a4ddcafc88a3bc53b2c28c30f14a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51465
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Clang 13 will put a “-1” inside a DWARF expression that's the difference
between two labels. We just need to pass it onto the output.
Change-Id: Ib58d245157a44ae9f1839c2af123bfe01791abf1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51445
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Change-Id: Ief328bb2a8b6264226a89233c9fba0e4621de9d7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51425
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
All FIPS testing is done with ACVP now. We can delete all the CAVP
stuff.
Change-Id: I459873474e40b0371f9cf760090a130ef9a90a8c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51330
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
FIPS validation requires showing that the continuous and start-up tests
are effective by breaking them. Traditionally BoringSSL used #defines
that tweaked the expected values. However, 140-3 now requires that the
inputs be changed, not the expected outputs.
Also, the number of tests is going to increase. Since slower platforms
already took too long to compile BoringSSL n times (once for each test
to break) we want something faster too.
Therefore all the known-answer tests (KATs) are changed such that a Go
program can find and replace the input value in order to break them.
Thus we only need to recompile once to disable the integrity test.
The runtime tests still need a #define to break, but that #define is now
put in a header file so that only the module need be recompiled, not
everything as in the previous system.
Change-Id: Ib621198e6ad02253e29af0ccd978e3c3830ad54c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51329
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Builds that compile the FIPS stuff separately don't get this header from
other files.
Change-Id: I8a1b30ae360b08d4f4b9f804cd234998889477bc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51405
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
AS10.20 requires that the self-test for the integrity algorithm pass
before the integrity check itself. IG 10.3.A requires an HMAC self-test
now. Therefore run these tests before the integrity check.
Since we also need the ability to run all self-tests, both SHA
self-tests and the HMAC test are run again when running self-tests.
I'm assuming that they're so fast that it doesn't matter.
Change-Id: I6b23b6fd3cb6107edd7420bc8680780719bd41d2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51328
Reviewed-by: David Benjamin <davidben@google.com>
The word “calculated” is two letters longer than “expected” and it's
nice to line up the ouptuts.
Change-Id: Idac70e62d98fbe26c430f03f4643ba295e40853d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51327
Reviewed-by: David Benjamin <davidben@google.com>
The provision of FIPS that allowed the tests to be skipped based on a
flag-file has been removed in 140-3. Therefore we expect to run the fast
KATs on start-up, but to defer to slower ones until the functionality in
question is first used. So this change splits off the fast KATs and
removes support for skipping KATs based on a flag-file.
Change-Id: Ib24cb1739cfef93e4a1349d786a0257ee1083cfb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51326
Reviewed-by: David Benjamin <davidben@google.com>
ACVP authorisation tokens expire and, once expired, need to be renewed
by sending a new TOTP code. We almost never hit this but some FIPS
modules are slow enough that they can't compute the response within the
token lifetime.
But the ACVP code was putting an Authorization header on the renewal
message because it put that header on every message. But doing so breaks
the renewal because the server rejects the request because the token has
expired before noticing that it's a renewal request.
Also, put a 10 second buffer on deciding if a token has expired to
account for the transmission delay.
Change-Id: I50643a223cdb313d07dd7b2c559ad160cbe608ff
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51385
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Now that the naming for Apple platforms is aligned, we can select the
variable uniformly.
Change-Id: Id547d1a4ba0585d5f9e4ea0b5d8b255b2ab2ec38
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51345
Reviewed-by: Adam Langley <agl@google.com>
The current names are confusing because (ios, aarch64) is also used on
macOS. The various Apple platforms all use the same ABI, and aarch64 is
no longer limited to iOS. (For that matter, the iOS simulator on x86
Macs is x86 iOS.) Just call it 'apple'.
Update-Note: References to 'mac' or 'ios' source lists in downstream
builds should be renamed to 'apple'.
Change-Id: Id1a0627f8ce3241f34ffa6bb245ee5783adc7c15
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51307
Reviewed-by: Adam Langley <agl@google.com>
https://boringssl-review.googlesource.com/c/boringssl/+/51265 broke
Linux and macOS platforms on architectures where we don't build
assembly. OPENSSL_NO_ASM needs to match the assembly selector.
While I'm here, remove the OPENSSL_C11_ATOMIC comment. We autodetect
atomics these days, so the flag is only useful if you want to force it.
Change-Id: I1f20f7577b5ca7e208dc90fb46a93b20da864ec5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51305
Reviewed-by: Piotr Sikora <piotrsikora@google.com>
Reviewed-by: Adam Langley <agl@google.com>
In testing out the ECH bits on the Chromium side, it is much harder to
tell what's going on without some indication that we sent a
ClientHelloInner. This CL routes it into the callback. A corresponding
CL in Chromium will add it to NetLog.
Bug: 275
Change-Id: I945ab2679614583e875a0ba90d6cf1481ed315d9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51205
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Both call sites end up calling them in succession. This saves a little
bit of code.
Bug: 275
Change-Id: Ib87bd9be446c368f77beb3b329deaa84ef43ac95
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51186
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The ECH extension is not covered in the AAD and so should not be
referenced in ech_outer_extensions. We end up rejecting this anyway when
checking for valid ClientHelloInners, but better to reject this
explicitly, as the spec suggests.
As part of this, use the more specific error in the various tests, so we
can distinguish the two cases. (DECODE_ERROR is coming from an extra,
probably unnecessary, error in ssl_decode_client_hello_inner's caller.)
Bug: 275
Change-Id: Ibeff55e5e1b7646ce9c68c5847cd1b40a47e6480
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51185
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Description:
Mark Wooden and Franck Rondepierre noted that the square-root-mod-p
operations used in the EdDSA RFC (RFC 8032) can be simplified. For
Ed25519, instead of computing u*v^3 * (u * v^7)^((p-5)/8), we can
compute u * (u*v)^((p-5)/8). This saves 3 multiplications and 2
squarings. For more details (including a proof), see the following
message from the CFRG mailing list:
https://mailarchive.ietf.org/arch/msg/cfrg/qlKpMBqxXZYmDpXXIx6LO3Oznv4/
Testing:
Build and run the Ed25519 tests:
mkdir build
cd build
cmake -GNinja ..
ninja && ./crypto/crypto_test --gtest_filter="Ed25519Test*"
Numerical testing of the square-root computation can be done using the
following sage script:
def legendre(x,p):
return kronecker(x,p)
# Ed25519
p = 2**255-19
# -1 is a square
if legendre(-1,p)==1:
print("-1 is a square")
# 2 is a non-square
if legendre(2,p)==-1:
print("2 is a non-square")
# 2 is a generator
# this can be checked by factoring p-1
# and then showing 2**((p-1)/q) != 1 (mod p)
# for all primes q dividing p-1.
# suppose u/v is a square.
# to compute one of its square roots, find x such that
# x**4 == (u/v)**2 .
# this implies
# x**2 == u/v, or
# x**2 == -(u/v) ,
# which implies either x or i*x is a square-root of u/v (where i is a square root of -1).
# we can take x equal to u * (u*v)**((p-5)/8).
g = 2
s = p>>2 # s = (p-1)/4
i = power_mod(g, s, p)
t = p>>3 # t = (p-5)/8
COUNT = 1<<18
while COUNT > 0:
COUNT -= 1
r = randint(0,p-1) # r = u/v
v = randint(1,p-1)
u = mod(r*v,p)
# compute x = u * (u*v)**((p-5)/8)
w = mod(u*v,p)
x = mod(u*power_mod(w, t, p), p)
# check that x**2 == r, or (i*x)**2 == r, or r is not a square
rr = power_mod(x, 2, p)
if rr==r:
continue
rr = power_mod(mod(i*x,p), 2, p)
if rr==r:
continue
if legendre(r,p) != 1:
continue
print("failure!")
exit()
print("passed!")
Change-Id: Iaa284d3365dd8c9fa18a4584121013f05a3f4cc6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50965
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This matches the source, which only builds support for these tests on
Linux. Note Android sets CMAKE_SYSTEM_NAME to "Android", so this covers
the previous ANDROID check.
Bug: 476
Change-Id: I41ca408706d0d0c5bb22006f4c31d51fc1267f69
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51165
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Upstream used the macro originally, but later added a bespoke
implementation to transparently support X9.42 DH parameter serialization
(DHXPARAMS in OpenSSL) in 2ca873e8d898e8a232ea707227400213980059a4.
We don't support DHXPARAMS, so revert to the macro.
Change-Id: Ib17902c6c640bb88ee55881945ce57a032f7061b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51105
Reviewed-by: Adam Langley <agl@google.com>
POSIX feature macros are a mess. Reportedly, FreeBSD also breaks with
_XOPEN_SOURCE, so try leaving it unset by default.
Update-Note: It's possible this will break yet another obscure UNIX.
Hopefully we can eventually find a combination that works?
Bug: 471
Change-Id: I103f8093110d343789b9c5a22eb056ab78d9cd14
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51145
Reviewed-by: Adam Langley <agl@google.com>
u8 strings in C++20 are char8_t instead of char; in order to compile on
both C++17 and C++20 we need to remove the prefix.
Change-Id: I85d1a9d72d24e8fa96ca22b1d99be9982fee8fb5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51065
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This hash table, in applications that use pooling, can dedup received
certificates in memory and thus should use a keyed hash.
Change-Id: Idc40dc8f7463025183121642b30ea0de43ebac0e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51125
Reviewed-by: Adam Langley <agl@google.com>
The check finds implicit conversions of integer literals to bools:
bool b1 = 1;
bool b2 = static_cast<bool>(1);
and transforms them to:
bool b1 = true;
bool b2 = true;
Bug: chromium:1290142
Change-Id: I15579e28f544d07b331a230b70a8278e0651150d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51085
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
See https://fuchsia-review.googlesource.com/c/fuchsia/+/624684. Also
pick up the new, more specific, name for ZX_ARM64_FEATURE_ISA_SHA2.
Update-Note: This CL is written assuming we can just rely on the SDK
changes. Per go/fuchsia-sdk-age, this seems fairly safe. If this file
fails to build due to missing symbols, update your project's Fuchsia
SDK. If this blocks something, let us know.
Change-Id: I28b0c234b577cc0de90e7ef096c15bb75a4ba501
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50926
Reviewed-by: Adam Langley <agl@google.com>
This is designed to be the minimal infrastructure required to support
using BoringSSL in the Rust ecosystem without fear of ABI drift. Bindgen
is used to generate Rust bindings in lockstep with the rest of the
build. `rust-openssl` can consume these generated bindings with minimal
changes.
Change-Id: I1dacd36a4131e22a930ebb01da00407e8465ad7e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49645
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Description:
Creating just a Gerrit password isn't enough. Before you can push a
change to Gerrit, you must also create/associate a Gerrit account with
the google account used to create the password.
This avoids "git push ..." rejections like this:
remote: PERMISSION_DENIED: The caller does not have permission
remote: [type.googleapis.com/google.rpc.LocalizedMessage]
remote: locale: "en-US"
remote: message: "\'git push\' requires a Gerrit user account."
Change-Id: Id02c1a69ccb0c2b8bf4c63b77ed3064125966eb3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50985
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This matches our other free functions.
Fixed: 473
Change-Id: Ie147995c2f5b429f78e95cfc9a08ed54181af94e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51005
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
140-3 says
> the zeroisation of protected and unprotected SSPs
> shall be performed in the following scenarios:
> ...
> For temporary value(s) generated during the integrity test of the
> module’s software or firmware upon completion of the integrity test.
(IG 9.7.B)
Change-Id: I911f294860bf33b13b2c997fc633c9bda777fc48
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50945
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Change-Id: If28138bbda4111b4a62f48cd30c7a71a675e44f7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50885
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Change-Id: Ic3305debe9c5d85b1c47be4ebcdfcbd0660f49af
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50865
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
OpenSSL's assembly files have a few places where we condition code on
__ARM_ARCH__, the minimum target ARM revision. It currently only
controls some pre-ARMv7 code. This symbol has, from what I can tell, the
same semantics as __ARM_ARCH, defined in Arm C Language Extensions, and
added in GCC 4.8 and Clang 3.2:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9e94a7fc5ab770928b9e6a2b74e292d35b4c94da;hp=25bab91e017eb1d6d93117f3da96fa9b43703190e98c4dbd1e
Those are over nine years old, so drop all the fallback code. Also fix
arm_arch.h to be includable on non-ARM platforms. Some tools expect all
public headers to be cleanly includable and arm_arch.h being "public"
was getting in the way (see cl/416881417).
Interestingly, arm_arch.h previously only computed __ARM_ARCH__ for
__GNUC__ and Clang doesn't define __GNUC__ on Windows. That means we
actually weren't defining __ARM_ARCH__ for Windows. But none of the
aarch64 assembly has __ARM_ARCH__-gated code, so it works out. If it
ever does, that CL smooths that over. I've gated the
__ARM_(MAX_)_ARCH__ bits on __ASSEMBLER__ to avoid breaking no-asm
Windows/aarch64 builds on MSVC. There aren't any uses in C.
Update-Note: ARM assembly now requires the compiler define __ARM_ARCH.
This is not expected to break Clang or GCC from the last 8 or 9 years.
Change-Id: Id45e95406edeecf8dda11dce9e82418516e9de1f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50849
Reviewed-by: Adam Langley <agl@google.com>
GCC's __ARMEL__ and __ARMEB__ defines denote little- and big-endian arm,
respectively. They are not defined on aarch64, which instead use
__AARCH64EL__ and __AARCH64EB__.
However, OpenSSL's assembly originally used the 32-bit defines on both
platforms and even define __ARMEL__ and __ARMEB__ in arm_arch.h. This is
less portable and can even interfere with other headers, which use
__ARMEL__ to detect little-endian arm. (Our own base.h believes
__ARMEL__ implies 32-bit arm. We just happen to check __AARCH64EL__
first. base.h is probably also always included before arm_arch.h.)
Over time, the aarch64 assembly has switched to the correct defines,
such as in 32bbb62ea634239e7cb91d6450ba23517082bab6. This commit
finishes the job.
(There is an even more official endianness detector, __ARM_BIG_ENDIAN in
the Arm C Language Extensions. But I've stuck with the GCC ones here as
that would be a larger change.)
See also https://github.com/openssl/openssl/pull/17373
Change-Id: Ic04ff85782e6599cdeaeb33d12c2fa8edc882224
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50848
Reviewed-by: Adam Langley <agl@google.com>
Adam Langley
David Benjamin
Piotr Sikora
James Muir
Mark Schott
Anton Bikineev
Benjamin Brittain