aarch64 assembly files use "//" as the comment indicator because '#'
indicates a constant value.
Change-Id: I53b18cbb3498522b0924716238abf55e6627d216
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44844
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Fuchsia is looking to remove the ZX_WAIT_ASYNC_ONCE constant, and our
copy of GoogleTest still has it. As usually with GoogleTest updates, our
old local patch is no longer necessary, but now we need a new one.
Change-Id: I8d226f01cf0951fd278605688684bf1ce3e17898
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44884
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This change causes the run_tests target, in FIPS builds, to run ACVP
for each supported algorithm. For most of them the output can be compared
against a known result. For some of them the output is too variable and
they are only run to ensure that they don't have local errors.
The ACVP test vectors have been trimmed significantly because they're
often huge. Firstly an included tool drops all but one test from each
group. Some vector sets have been manually trimmed to remove tests that
cause variable output.
Change-Id: Iff73851e3d47813041cc7ea6d881282750274940
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44746
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
One of the comments in e56dfcf9f4 was worded awkwardly. Thanks to Zi Lin
for fixing this.
Change-Id: I7ee647716e0ee30145bdce5be35128058130e1ec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44764
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Newer versions of LLVM may use profile information to put code in
sections named .text.unlikely.*. Make sure those sections end up in
our .text section.
Change-Id: Ia0224fd8e683f5e77c60dd3ad34d59b33f9b41ab
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44804
Commit-Queue: Peter Collingbourne <pcc@google.com>
Reviewed-by: Adam Langley <agl@google.com>
A couple of processing errors crept in over time. Caught by the tests
in the next change.
Change-Id: I0caa478d3321cb8a1da1e61ddde16ba8db91eb35
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44745
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The config file is only needed if interacting with an ACVP server.
Invocations that just want to process input from a file don't need it.
By moving this chunk of code down, the config isn't loaded until
after handling JSON inputs and just can be ignore if not needed.
Change-Id: Ibce334f63ddf8df34cf2917b923db20b3aaa735f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44744
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
BER permits lengths to be non-minimal. Previously this was not supported
at all. This change brings greater support, allowing non-minimal lengths
so long as they fit in a uint32_t.
Change-Id: I002ed2375c78fdb326e725eb1c23eca71ef9ba4a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44684
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This is so we can build the tool in Chromium and run benchmarks using
Chromium's build config.
Change-Id: I16b4d99a923cd61f338ba488cb0abdfce3c0a3d2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44724
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This reflects an internal LSC cleanup.
Change-Id: Ic6d363ab14e0b021a579cdcf0a7a68a9021e2e18
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44664
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This moved, en masse, into the FIPS module in e7f08827d2. But we want to
minimise the amount that's in the FIPS module and it doesn't appear that
we need this at the current time.
Change-Id: Ib2c243aad461b716314eeeb6a460955818a7aa22
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44605
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
IETF QUIC draft 33 is replacing the TLS extension
codepoint for QUIC transport parameters from 0xffa5
to 57. To support multiple versions of Chrome, we
need to support both codepoints in BoringSSL. This
CL adds support for the new codepoint in a way that
can be enabled on individual connections.
Change-Id: I3bf06ea0710702c0dc45bb3ff2e3d772e9f87f9b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44585
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The headers aren't quite interchangeable. stdlib.h defines ::abort()
while cstdlib defines std::abort(). The Google style guide doesn't give
much guidance but says to match the existing style, so I've switched it
to stdlib.h.
See https://github.com/apple/swift-nio-ssl/issues/259
Change-Id: I19feb5213e123a88b381d6d8f8fe9d8e87c81e67
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44625
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
I accidentally lost these lines juggling patches around.
Change-Id: I35551eeb0f1bb26dee74344048198a318c55209b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44624
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Current:
Did 2916000 ChaCha20-Poly1305 (16 bytes) seal operations in 1015000us (2872906.4 ops/sec): 46.0 MB/s
Did 1604750 ChaCha20-Poly1305 (256 bytes) seal operations in 1016000us (1579478.3 ops/sec): 404.3 MB/s
Did 516750 ChaCha20-Poly1305 (1350 bytes) seal operations in 1015000us (509113.3 ops/sec): 687.3 MB/s
Did 99750 ChaCha20-Poly1305 (8192 bytes) seal operations in 1016000us (98179.1 ops/sec): 804.3 MB/s
Did 50500 ChaCha20-Poly1305 (16384 bytes) seal operations in 1016000us (49704.7 ops/sec): 814.4 MB/s
With fix:
Did 6366750 ChaCha20-Poly1305 (16 bytes) seal operations in 1016000us (6266486.2 ops/sec): 100.3 MB/s
Did 3938000 ChaCha20-Poly1305 (256 bytes) seal operations in 1016000us (3875984.3 ops/sec): 992.3 MB/s
Did 1207750 ChaCha20-Poly1305 (1350 bytes) seal operations in 1015000us (1189901.5 ops/sec): 1606.4 MB/s
Did 258500 ChaCha20-Poly1305 (8192 bytes) seal operations in 1016000us (254429.1 ops/sec): 2084.3 MB/s
Did 131500 ChaCha20-Poly1305 (16384 bytes) seal operations in 1016000us (129429.1 ops/sec): 2120.6 MB/s
Change-Id: Iec6417b9855b9d3d1d5154c93a370f80f219c65f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44347
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
If using precompiled headers then this is needed otherwise bn/internal.h
doesn't have a definition for BN_ULONG etc.
Change-Id: I41b331465abae7108f255722a156d2ffb3016ba3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44604
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This involves adding a new function |DH_compute_key_hashed| that
combines the FFDH with the output hashing inside the FIPS module. This
new function uses the padded FFDH output, as newly specified in SP
800-56Ar3.
Change-Id: Iafcb7e276f16d39bf7d25d3b2f163b5cd6f67883
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44504
Reviewed-by: David Benjamin <davidben@google.com>
This change also drops ex_data from DH objects. The global would need
special handling in the FIPS module, which isn't hard, but just dropping
it saves some of the code-size costs of this change and I cannot find
any signs of use of this functionality.
Change-Id: I984bd70698c2ec329f340d294b3b9ec169cd0c4e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44524
Reviewed-by: David Benjamin <davidben@google.com>
Imported from upstream's 617b49db14fa4c1211bfc5d0e88294d0f159c9a9.
Change-Id: I64349b7cbbda8fbacf1e20ca609081ed42f10550
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44565
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
As of
https://chromium-review.googlesource.com/c/chromium/tools/build/+/2586225,
we no longer test on Yasm. Yasm hasn't seen a release for over six years
now and is missing support for newer x86 instructions.
This removes the remnants of support for Yasm on the CI. It also removes
the Yasm support we patched into x86nasm.pl, which removes a now
unnecessary divergence from upstream.
Update-Note: If a x86 Windows asm build breaks, switch from Yasm to
NASM. We're also no longer testing NASM on x86_64 Windows, but there
wasn't any patch to revert.
Change-Id: I016bad8757fcc13240db9f56dd622be518e649d7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44564
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Rather than the FIPS module actively collecting entropy from the CPU or
OS, this change configures Android FIPS to passively receive entropy.
See FIPS IG 7.14 section two.
Change-Id: Ibfc5c5042e560718474b89970199d35b67c21296
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44305
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This should fix the Chromium roll.
Windows shared library builds are fussy about dllexport vs. dllimport in
a way that's incompatible with external uses of the asn1t.h macros. The
issue is the DECLARE_* macros will add dllexport vs. dllimport on the
assumption the symbols are defined in libcrypto, but external
definitions need a different selector.
Rather than add more complex macros for this, just exclude those tests.
Ideally we wouldn't supoport asn1t.h outside the library at all, if we
can manage it, so no sense in trying to make it work.
This excludes both the new and the old tests. Although this has been
working thus far, it only works because we've been setting the
BORINGSSL_IMPLEMENTATION symbol for test targets wrong in Chromium. I'm
confused how that's been working at all (maybe dllexport vs. dllimport
is more lax when it comes to functions rather than variables?), but when
I do it correctly, the ASN1_LINKED_LIST template breaks too.
Change-Id: I391edba1748f66c383ed55a9d23053674bbb876e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44484
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
8846533744 added a “power-on” test for the TLS KDF, but omitted to add
it to the documented list of these tests.
Change-Id: I13dbad4b9359e7dae0938d02ac53e5e011f50824
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44505
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This imports d741debb320bf54e8575d35603a44d4eb40fa1f9 from upstream.
We've been managing the shared libraries already because our
arm-xlate.pl automatically adds .hidden to .extern lines, but nice to
reduce the diff. (This does result in some duplicate .hidden lines in
the generated output, but we still want the arm-xlate.pl patch to
automatically hide .globl.)
Removing .comm lines does change the generated output, but having each
asm file define its own copy of OPENSSL_armcap_P as a common symbol
always seemed odd. I recall some weird issue where the armv4.pl files
subtly rely on it for iOS's strange .indirect_symbol machinery. (Not
actually because iOS wants a common symbol but because arm-xlate.pl
repurposes .comm to trigger .indirect_symbol.) Fortunately, aarch64 is
much better about PC-relative addressing, so it should be a no-op.
The .comm lines have also previously caused weird issues
(https://boringssl-review.googlesource.com/c/boringssl/+/32324), so
it's generally nice to get rid of them.
Update-Note: If aarch64 builds get some weird error about relocations,
it's this CL's fault.
Change-Id: I763ffa6cda750d99694ded8a5b68d7b27b09cfc9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44464
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This imports 1ecc76f6746cefd502c7e9000bdfa4e5d7911386 and
41d62636fd996c031c0c7cef746476278583dc9e from upstream. These would have
rejected the mistake in OpenSSL's EDIPartyName sturcture.
Change-Id: I4eb218f9372bea0f7ff302321b9dc1992ef0c13a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44424
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This change tweaks our ACVP config to better match what BoringCrypto
has previously tested with CAVP.
Change-Id: I7d7ce5153a3eb7355ae1516f06ff591ee2c9d902
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44385
Reviewed-by: David Benjamin <davidben@google.com>
See also CVE-2020-1971, f960d81215ebf3f65e03d4d5d857fb9b666d6920, and
aa0ad2011d3e7ad8a611da274ef7d9c7706e289b from upstream OpenSSL.
Unlike upstream's version, this CL opts for a simpler edipartyname_cmp.
GENERAL_NAME_cmp is already unsuitable for ordering, just equality,
which means there's no need to preserve return values from
ASN1_STRING_cmp. Additionally, the ASN.1 structure implies most fields
cannot be NULL.
(The change from other to x400Address is a no-op. They're the same type.
Just x400Address is a little clearer. Historical quirks of the
GENERAL_NAME structure.)
Change-Id: I4b0ffe8e931c8ef916794a486e6a0d6d684c0cc1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44404
Reviewed-by: Adam Langley <agl@google.com>
It's insufficient to signal an error when the PWCT fails. We
additionally need to ensure that the invalid key material is not
returned.
Change-Id: Ic5ff719a688985a61c52540ce6d1ed279a493d27
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44306
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
If I perturb kOrder in the malleability check, our and Wycheproof's
tests don't easily notice. This adds some tests with s above and below
the order. EdDSA hashes the public key with the message, which
frustrates constructing actual boundary cases. Instead, these inputs
were found by generating many signatures.
This isn't ideal, but it is sensitive to the most significant 32 bits.
Change-Id: I7fc03758ab97650d0e94478f355ea7085ae0559a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44346
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: Iba527924a79733b28b12b65d8e1f613d7819eb34
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44345
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
<openssl/base.h> checks for a supported platform, but we don't check
endianness of ARM and MIPS, which are bi-endian. See
https://crbug.com/1153312#c7.
Switch this around. Documentation on which define is "official" is hard
to come by, so I mostly mimicked Chromium. Chromium detects
little-endian ARM and MIPS with __ARMEL__ and __MIPSEL__ respectively,
without looking at __arm__ or __mips__. It uses __aarch64__
instead of __AARCH64EL__, but I think that's an oversight. I can get
Clang to output for aarch64_be and that defines __aarch64__ with
__AARCH64EB__.
<openssl/arm_arch.h> (which we should simplify and align with base.h
once this CL sticks) also normalizes to __ARMEL__ over __BYTE_ORDER__
and friends. Although, interestingly, arm_arch.h defines its own
__ARMEL__ on GNUC aarch64, even though Clang does *not* define __ARMEL__
on aarch64. (I'm guessing this aligned for the benefit of the "armx"
bi-arch asm files.) This value is based on __BYTE_ORDER__, not
__ARMEL__, but it assumes GNUC arm always defines __ARMEL__, so I think
it's reasonable to assume GNUC aarch64 always defines __AARCH64EL__.
Given all this, probably the simplest thing that's most likely to work
is to use __ARMEL__, __MIPSEL__, and __AARCH64EL__. Note this does not
change the _M_* checks. _M_* are Windows's definitions, which I think we
can reasonably assume come with an endianness opinion. (Windows' ARM and
ARM64 ABIs mandate little-endian.) This aligns with Chromium.
Update-Note: CPU processor defines are a mess. If a little-endian ARM or
MIPS build breaks, some of the assumptions above may be wrong. In that
case, the output $CC -dM -E - < /dev/null on the offending toolchain
will be useful to fix it. If a big-endian ARM or MIPS build breaks, this
is working as intended. Any resulting binaries weren't producing the
right outputs.
Change-Id: I2a9e662d09df119a71226e91716d84e7ac3792aa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44324
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
ARM Cortex-A57 and Cortex-A72 cores running in 32-bit mode are affected
by silicon errata #1742098 [0] and #1655431 [1], respectively, where the
second instruction of a AES instruction pair may execute twice if an
interrupt is taken right after the first instruction consumes an input
register of which a single 32-bit lane has been updated the last time it
was modified.
Shuffle the counter assignments around a bit so that the most recent
updates when the AES instruction pair executes are 128-bit wide.
[0] ARM-EPM-049219 v23 Cortex-A57 MPCore Software Developers Errata Notice
[1] ARM-EPM-012079 v11.0 Cortex-A72 MPCore Software Developers Errata Notice
(This is imported from upstream's
409c59e8f44ae56f2587cdd8a7ce611d0e3d91d9.)
The change is applied to both 32-bit and 64-bit for simplicity, but there
was no measurable performance difference, so leaving them aligned is
easiest.
Change-Id: Ic8e5f656f59ae8c2ecb2762a066c2c9064bb34c5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44284
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
No need to use |sk_new|, which allocates a buffer that will immediately
be realloced.
Change-Id: If0a787beac19933d93c5f9a3a8b560edd027c16c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44205
Reviewed-by: Adam Langley <agl@google.com>
Clarify that there are no truncation issues on targets where the range
of |unsigned| is smaller than the range of |size_t|.
Ensure that |poly1305_state| is (still) large enough. This is a good
idea independently of this change, but is especially important because
switching the fields to |size_t| might have enlarged the structures.
Change-Id: I16e408229c28fcba6c3592603ddb9431cf1f142d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44244
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The docs at os/signal.Notify warn about this signal delivery loss bug at
https://golang.org/pkg/os/signal/#Notify, which says:
Package signal will not block sending to c: the caller must ensure
that c has sufficient buffer space to keep up with the expected signal
rate. For a channel used for notification of just one signal value,
a buffer of size 1 is sufficient.
Discovered by one of Orijtech, Inc's internal static
analyzers that will eventually be donated to the Go project, and will
then be included when one runs:
go test
Change-Id: I5713f7087a195ac706240d32b53d2e4855d93a1c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44264
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This covers the use of EVP_sha256() added in 8846533744.
Change-Id: I8cd4c8e271de6a0b9a926e7186c7b24ffe849d67
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44224
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Almost everything in <openssl/asn1.h> uses ASN1_STRING, and there are a
lot of unspoken assumptions in the library about the type field, so it
needs quite a bit of text.
Change-Id: Ied56c9428069477da8ecb17a174da4320e573fa1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44184
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I08cc198f326f02b3f38234b938208ea49a13fab6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44164
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Adam Langley
David Benjamin
Dan McArdle
Peter Collingbourne
David Schinazi
Vlad Krasnov
Adam Langley
Aaron zhang
Brian Smith
Emmanuel T Odeke