In trying to figure out an ARM64 builder issue, I tried VS2019. That
didn't fix the ARM64 issue, but it did reveal that I ported over some of
the logic from Chromium wrong. For "new-style" paths, the toolchain
directory should be toolchain_data['path'], not the parent directory of
win_sdk.
(The latest VS2019 package in Chromium puts win_sdk a few directories
down from the toolchain root.)
This CL should be a no-op for now because all our current toolchains use
Chromium's "old-style" win_sdk-relative paths.
Change-Id: I8ad7784abb479d1ede3995a44433e57448e8debf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45744
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This reverts commit 4251d0d3f66a182e1b1ff22e9d0085613a1253ec, except
that the reland dates have been updated to not be in the past.
Change-Id: I7812c0e36d87ed1e049ec0a7d92a23efec881a81
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45704
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
I've left libc++ and Android tools for now. libc++ is running into
https://crbug.com/1166707. I'm not sure what's wrong with the Android
tools. (CMAKE_LINKER isn't defined for some reason, but it's defined on
my machine.)
We'll also want to update the builders before the NDK anyway. The new
NDK now defaults to ANDROID_ARM_NEON=TRUE.
Change-Id: I1c0fbc3e26368c04d31464477a51e04209aec7ba
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45544
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
While I'm here, rewrite it a bit to align more with our preferred style.
(No assignments in conditions, no need for NULL checks on free
functions.)
See also 64a1b940d2b640e5edf0feae90e81bbb6b4941e7 from upstream.
Change-Id: I99a122343541e89d5950888de2c708cfa3ec45e2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45686
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CVE-2021-23840
(Imported from upstream's 6a51b9e1d0cf0bf8515f7201b68fb0a3482b3dc1.)
This differs slightly from upstream's version:
- EVP_R_OUTPUT_WOULD_OVERFLOW didn't seem necessary when ERR_R_OVERFLOW
already exists. (Also since we use CIPHER_R_*, it wouldn't have helped
with compatibility anyway. Though there's probably something to be
said for us folding CIPHER_R_* back into EVP_R_*.)
- For simplicity, just check in_len + bl at the top, rather than trying
to predict the exact number of bytes written.
Update-Note: Passing extremely large input lengths into EVP_CipherUpdate
will now fail. Use EVP_AEAD instead, which is size_t-based and has more
explicit output bounds.
Change-Id: I31835c89dcdecb6b112828f57deb798dc7187db5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45685
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Update-Note: No one uses this function. It had a NULL dereference in
some error cases. See CVE-2021-23841.
Change-Id: Ie1cc97615ac8b674147715d7d62e62faf218ae65
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45684
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This fixes an issue in a99308f that caused Bazel builds to break during
the analysis phase.
Change-Id: Ib26e70a52730f04905c2b2f137674f297488ec4f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45665
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This lets the builders pass it in via gclient_vars. Once this lands,
I'll make the builders fill it in, at which point we can remove the
magic 'env' value and the logic in the recipe.
Change-Id: Idfc4db3e4cdecf62eacbb2925fd545e1a76b2c79
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45624
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Newer versions of Bazel use a different setting for the crosstool_top
flag, depending on the NDK toolchain in use. This change detects these
crosstools and builds them using Android flags.
Fixes: 180083900
Change-Id: I937d18e53d72b2911e1c472adbce65282d31885d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45564
Commit-Queue: Justin Paupore <jpaupore@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This aligns with OpenSSL's behavior. RFC7301 says servers should return
no_application_protocol if the client supported ALPN but no common
protocol was found. We currently interpret all values as
SSL_TLSEXT_ERR_NOACK. Instead, implement both modes and give guidance on
whne to use each. (NOACK is still useful because the callback may be
shared across multiple configurations, some of which don't support ALPN
at all. Those would want to return NOACK to ignore the list.)
To match upstream, I've also switched SSL_R_MISSING_ALPN, added for
QUIC, to SSL_R_NO_APPLICATION_PROTOCOL.
Update-Note: Callers that return SSL_TLSEXT_ERR_ALERT_FATAL from the
ALPN callback will change behavior. The old behavior may be restored by
returning SSL_TLSEXT_ERR_NOACK, though see the documentation for new
recommendations on return values.
Change-Id: Ib7917b5f8a098571bed764c79aa7a4ce0f728297
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45504
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Sometimes JSON vector files contain a header element that must be
duplicated into the output and sometimes they don't. Auto-detect this by
looking for a “url” field in the first element.
Change-Id: I76046adb8ea64fe5ac9bae9d6583546504723918
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45524
Reviewed-by: David Benjamin <davidben@google.com>
Use Fiat Crypto for non-x86_64 platforms, like BoringSSL. Continue
using the nistz256 code on Windows, differently from BoringSSL.
Make *ring* more consistent with BoringSSL.
Don't require a specialized implementation of field element addition for
each curve; instead share an implementation between RSA and ECC.
Refactor the code to avoid needing `elem_sum`.
This is largely some cleanup so the three features follow the same
patterns and is hopefully cleaner (no more separate static and
non-static paths). The practical impact is probably nil. (Linux-based
ARM builds with crypto extensions as a baseline, if any exist, save
binary size.)
Change-Id: I2214b1a54e2074024b8eeb51799a08b94646cbf3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45485
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Emulate the `copy_within` API so that the use of `unsafe` can be isolated
into a single place.
Remove the test for encryption into disjoint buffers. We should expose
such an API in the future, but currently we don't, so this was testing a
scenerio that would never occur. Removing this part of the test was
necessary to enable this refactoring. We'll need to bring it back when
we implement out-of-place encryption.
When a feature is enabled statically in the build config, the compiler
defines __ARM_NEON and also considers itself free to emit NEON code.
In this case, there is no need to check for NEON support at runtime
since the binary will not work without NEON anyway. Moving the check to
compile time lets us drop unused code.
Chrome has required NEON on Android for nearly five years now. However,
historically there was a bad CPU which broke on some NEON code, but not
others. See https://crbug.com/341598 and https://crbug.com/606629. We
worked around that CPU by parsing /proc/cpuinfo and intentionally
dropping the optimization. This is not a stable situation, however, as
we're hoping the compiler is not good enough at emitting NEON to trigger
this bug.
Since then, the number of affected devices has dropped, and Chrome has
raised the minimum Android requirement to L. The Net.HasBrokenNEON
metric from Chrome is now well in the noise.
This CL stops short of removing the workaround altogether because some
consumers of Cronet are unsure whether they needed this workaround.
Those consumers also build without __ARM_NEON, so gating on that works
out. We'll decide what to do with it pending metrics from them.
Update-Note: Builds with __ARM_NEON (-mfpu=neon) will now drop about
30KiB of dead code, but no longer work (if they even did before) on a
particular buggy CPU. Builds without __ARM_NEON are not affected.
Change-Id: Id8f7bccfb75afe0a1594572ea20c51d275b0a256
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45484
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
When the test was originally written, it was calling the assembly
function directly. Now it is calling the wrapper that works around the
problem, so we can verify that the workaround works.
CMAC-AES isn't inside our FIPS module, it's only included in
modulewrapper in order to test acvptool. Mark it with a special tag to
avoid it appearing when dumping regcap JSON because NIST paperwork is
such that it's better not to ACVP test such code.
Change-Id: I0c6d3a38bce9bf5766b889677eb3f7de94262c24
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45465
Reviewed-by: David Benjamin <davidben@google.com>
This is only used for testing acvptool but, yea, |memcmp| doesn't return
a bool 😳
This wasn't noticed because "ver" mode was missing from the registration
and thus from the test vectors.
Change-Id: I181c9b66aea4032543d39ebcc8728a01e0f34f55
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45464
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The code had this comment:
```
/// XXX: Although this takes an `Iv`, this actually uses it like a
/// `Counter`.
```
With the recent refactorings we can fix the type to be `&Counter`. Further
we can get rid of `CounterOrIv`.
Ensure we're always passing in u32-aligned values to `GFp_ChaCha20_ctr32`.
Get rid of the attempt to abstract away the difference between ChaCha20
and AES-CTR w.r.t. counters and IVs. The abstraction wasn't actually used
by any shared code. The AES-CTR (GCM) code does endian conversion in the
assembly so endian conversion cannot easily be deferred to later. For
ChaCha20, it makes more sense to do endian conversion at the time of
`Counter`/`Iv` construction. Despite the slight duplication of logic in
having two `Counter` types and two `Iv` types, this is actually a net
reduction of code. If we ever have a third implementation of these types
we can apply the Rule of Three to factor out the commonality.
This will let us simplify `aead::block`.
The previous implementation of `poly1305_update_padded_16` was optimized for
the API of the earlier Poly1305 implementation, and was duplicating some
I-U-F logic from the current Poly1305 implementation. Simplify it to avoid
that duplication.
Many (most?) KDFs are infallible, so optimize for that case. If the KDF
is fallible then the result will be `Ok(Err(_))` which is messy.
This eliminates the `error_value` parameter.
test_fips probably needs to exercise everything that we have self-tests
for.
(The following change will eliminate the duplication of the code to
create the FFDH group. For reasons, that can't be done in this change.)
Change-Id: Ia72064db77381e7cf396a34b4723b2607f26f00b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45404
Reviewed-by: Adam Langley <alangley@gmail.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This fixes the build for folks not using bcm.c.
Change-Id: I47935d8af7cb5a12ff2918ee2a8774182681d930
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45384
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This reverts commit 5850a016b212407708a963f4f94e4217ae18dd0e.
Bug: 375
Change-Id: Ife8184ded5b09f175924bfc29ac113d3186e60ed
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45344
Reviewed-by: David Benjamin <davidben@google.com>
The check was happening in code that only ran at TLS 1.2, so we weren't
testing anything. Additionally check the resumption case. While we do
handle it correctly, we only manage it due to the weird OpenSSL quirk
we've carried over from TLS 1.2 tickets where we synthesize a session ID
for TLS 1.3 tickets. (Is that still needed?)
That's subtle enough to warrant a test, and some other implementations
reuse our test suite, so it's worth the coverage there.
Change-Id: I83cc355bd853097ec6edcd2cc40b06b19e3b00e5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45324
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
