The Clang used in the Android SDK, at least, defines both __ARM_NEON__
and __ARM_NEON for ARMv7, but only the latter for AArch64.
This change switches each use of __ARM_NEON__ to accept either.
Change-Id: I3b5d5badc9ff0210888fd456e9329dc53a2b9b09
Reviewed-on: https://boringssl-review.googlesource.com/c/33104
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This removes the failure cases for cmp_x_coordinate, this clearing our
earlier dilemma.
Change-Id: I057f705e49b0fb5c3fc9616ee8962a3024097b24
Reviewed-on: https://boringssl-review.googlesource.com/c/33065
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This is in preparation for removing the BIGNUM from cmp_x_coordinate.
Change-Id: Id8394248e3019a4897c238289f039f436a13679d
Reviewed-on: https://boringssl-review.googlesource.com/c/33064
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
I forgot to refresh the public key in those tests, so they weren't
actually testing what they were supposed to. With this fix, injecting
too larger of a P_MINUS_ORDER into p256-x86_64.c now breaks tests.
Change-Id: I5d10a85c84b09629448beef67c86de607525fc71
Reviewed-on: https://boringssl-review.googlesource.com/c/33044
Reviewed-by: Adam Langley <agl@google.com>
This function is not EC_METHOD-specific, nor is there any reason it
would be (we do not support GF2m).
Change-Id: I4896cd16a107ad6a99be445a0dc0896293e8c8f9
Reviewed-on: https://boringssl-review.googlesource.com/c/32884
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This is done in preparation of generalizing the optimization to all our
EC_METHODs.
Wycheproof happily does cover the case where x needed a reduction, but
they don't appear to check x being just above or below n, only x = p - 1
(adjusted downwards). Also we can tailor the test vectors a bit to the
x == r*z^2 (mod p) strategy to make sure we don't mess that up.
Additionally, the scenario is different for n > p. There is also the
nuisance of EC_FELEM vs EC_SCALAR having different widths. All our
built-in curves are well-behaved (same width, and consistently p < n),
but secp160r1 is reachable from custom curves and violates both
properties. Generate some tests to cover it as well.
Change-Id: Iefa5ebfe689a81870be21f04f5962ab161d38dab
Reviewed-on: https://boringssl-review.googlesource.com/c/32985
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Some of the ec files now reference ECDSA_R_BAD_SIGNATURE. Instead, lift the
error-pushing to ecdsa.c.
Change-Id: Ice3e7a22c5099756599df0ab0b215c0752ada4ee
Reviewed-on: https://boringssl-review.googlesource.com/c/32984
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This reverts commit e907ed4c4b. CPUID
checks have been added so hopefully this time sticks.
Change-Id: I5e0e5b87427c1230132681f936b3c70bac8263b8
Reviewed-on: https://boringssl-review.googlesource.com/c/32924
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Now that the tuned add/dbl implementations are exposed, these can be
specific to EC_GFp_mont_method and call the felem_mul and felem_sqr
implementations directly.
felem_sqr and felem_mul are still used elsewhere in simple.c, however,
so we cannot get rid of them yet.
Change-Id: I5ea22a8815279931afc98a6fc578bc85e3f8bdcc
Reviewed-on: https://boringssl-review.googlesource.com/c/32849
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This reverts commit 3d450d2844. It fails
SDE, looks like a missing CPUID check before using vector instructions.
Change-Id: I6b7dd71d9e5b1f509d2e018bd8be38c973476b4e
Reviewed-on: https://boringssl-review.googlesource.com/c/32864
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Some consumer stumbled upon EC_POINT_{add,dbl} being faster with a
"custom" P-224 curve than the built-in one and made "custom" clones to
work around this. Before the EC_FELEM refactor, EC_GFp_nistp224_method
used BN_mod_mul for all reductions in fallback point arithmetic (we
primarily support the multiplication functions and keep the low-level
point arithmetic for legacy reasons) which took quite a performance hit.
EC_FELEM fixed this, but standalone felem_{mul,sqr} calls out of
nistp224 perform a lot of reductions, rather than batching them up as
that implementation is intended. So it is still slightly faster to use a
"custom" curve.
Custom curves are the last thing we want to encourage, so just route the
tuned implementations out of EC_METHOD to close this gap. Now the
built-in implementation is always solidly faster than (or identical to)
the custom clone. This also reduces the number of places where we mix
up tuned vs. generic implementation, which gets us closer to making
EC_POINT's representation EC_METHOD-specific.
Change-Id: I843e1101a6208eaabb56d29d342e886e523c78b4
Reviewed-on: https://boringssl-review.googlesource.com/c/32848
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This commit improves the performance of ECDSA signature verification
(over NIST P-256 curve) for x86 platforms. The speedup is by a factor of 1.15x.
It does so by:
1) Leveraging the fact that the verification does not need
to run in constant time. To this end, we implemented:
a) the function ecp_nistz256_points_mul_public in a similar way to
the current ecp_nistz256_points_mul function by removing its constant
time features.
b) the Binary Extended Euclidean Algorithm (BEEU) in x86 assembly to
replace the current modular inverse function used for the inversion.
2) The last step in the ECDSA_verify function compares the (x) affine
coordinate with the signature (r) value. Converting x from the Jacobian's
representation to the affine coordinate requires to perform one inversions
(x_affine = x * z^(-2)). We save this inversion and speed up the computations
by instead bringing r to x (r_jacobian = r*z^2) which is faster.
The measured results are:
Before (on a Kaby Lake desktop with gcc-5):
Did 26000 ECDSA P-224 signing operations in 1002372us (25938.5 ops/sec)
Did 11000 ECDSA P-224 verify operations in 1043821us (10538.2 ops/sec)
Did 55000 ECDSA P-256 signing operations in 1017560us (54050.9 ops/sec)
Did 17000 ECDSA P-256 verify operations in 1051280us (16170.8 ops/sec)
After (on a Kaby Lake desktop with gcc-5):
Did 27000 ECDSA P-224 signing operations in 1011287us (26698.7 ops/sec)
Did 11640 ECDSA P-224 verify operations in 1076698us (10810.8 ops/sec)
Did 55000 ECDSA P-256 signing operations in 1016880us (54087.0 ops/sec)
Did 20000 ECDSA P-256 verify operations in 1038736us (19254.2 ops/sec)
Before (on a Skylake server platform with gcc-5):
Did 25000 ECDSA P-224 signing operations in 1021651us (24470.2 ops/sec)
Did 10373 ECDSA P-224 verify operations in 1046563us (9911.5 ops/sec)
Did 50000 ECDSA P-256 signing operations in 1002774us (49861.7 ops/sec)
Did 15000 ECDSA P-256 verify operations in 1006471us (14903.6 ops/sec)
After (on a Skylake server platform with gcc-5):
Did 25000 ECDSA P-224 signing operations in 1020958us (24486.8 ops/sec)
Did 10373 ECDSA P-224 verify operations in 1046359us (9913.4 ops/sec)
Did 50000 ECDSA P-256 signing operations in 1003996us (49801.0 ops/sec)
Did 18000 ECDSA P-256 verify operations in 1021604us (17619.4 ops/sec)
Developers and authors:
***************************************************************************
Nir Drucker (1,2), Shay Gueron (1,2)
(1) Amazon Web Services Inc.
(2) University of Haifa, Israel
***************************************************************************
Change-Id: Idd42a7bc40626bce974ea000b61fdb5bad33851c
Reviewed-on: https://boringssl-review.googlesource.com/c/31304
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I84cda22a1086bce0da4797afae7975b3f39625de
Reviewed-on: https://boringssl-review.googlesource.com/c/32844
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This is an extremely important and practical use case. The comment that
state->calls is bounded by the reseed interval isn't quite true. We only
check on entry to the function, which means that it may exceed it by one
call's worth. Switch it to a size_t (which doesn't actually increase
memory because the struct was already padded).
Change-Id: Ia7646fd5b4142789c1d613280223baa4cd1a4a9b
Reviewed-on: https://boringssl-review.googlesource.com/c/32804
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
0-RTT support and APIs to consume NewSessionTicket will be added in a
follow-up.
Change-Id: Ib2b2c6b618b3e33a74355fb53fdbd2ffafcc5c56
Reviewed-on: https://boringssl-review.googlesource.com/c/31744
Commit-Queue: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
tls_cbc.c is concerned with the variation in where the padding+mac may
end, counted in blocks. Hash blocks are larger than block cipher blocks,
and the hash itself appends some padding. Thus maximal padding off a
64-hash.Size() bytes may not fully stress things.
Just run all inputs modulo the hash block size, so we don't have to
think very hard about the "most difficult" input.
Change-Id: I8da1427dfff855931c14a9135c22afbff4f367c0
Reviewed-on: https://boringssl-review.googlesource.com/c/32724
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Symptom: When using larger hash functions and short messages,
these six blocks take too much time to be conditionally copied.
Observations:
- SHA-384 consumes more data per iteration, unlike SHA-256.
- The value of `kVarianceBlocks` must depend on the parameters
of the selected hash algorithm.
- Avoid magic constants.
Changes:
- A new formula for the kVarianceBlocks value.
- Stronger test vectors were created in change: 32724.
- The new formula passes these tests.
Discussion:
OpenSSL team: https://github.com/openssl/openssl/pull/7342
Quoting mattcaswell:
> The "real" data that needs to be hashed has to be padded for the
> hashing algorithm. For SHA1 the smallest amount of padding that
> can be added is the "0x80" byte plus 8 bytes containing the message
> length, i.e. 9 bytes. If the data length is within 9 bytes of the
> end of the hash block boundary then the padding will push it into
> an extra block to be hashed.
Change-Id: Id1ad2389927014316eed2b453aac6e4c2a585c5c
Reviewed-on: https://boringssl-review.googlesource.com/c/32624
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This function is not exported, so we don't need the optional BN_CTX
logic. Additionally, the cleanup code can be made a bit simpler and more
idiomatic.
Change-Id: Ib326eab4813fd9de9ac1df8fdc9e470c26aff092
Reviewed-on: https://boringssl-review.googlesource.com/c/32704
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
glibc didn't add getauxval or sys/auxv.h until 2.16. glib 2.16.0 is six
years old and thus glibc 2.15 is past our support horizon, however
Android is using an outdated sysroot. Temporarily allow this until they
fix their toolchain.
Change-Id: I24e231cf40829e446969f67bf15c32e0b007de4c
Reviewed-on: https://boringssl-review.googlesource.com/c/32686
Reviewed-by: Robert Sloan <varomodt@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Some versions of Android libc don't even include the header.
Change-Id: Ib1033d2b8a10ba69d834ac1ed2564870e0e35d61
Reviewed-on: https://boringssl-review.googlesource.com/c/32664
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
An EVP_AEAD_CTX used to be a small struct that contained a pointer to
an AEAD-specific context. That involved heap allocating the
AEAD-specific context, which was a problem for users who wanted to setup
and discard these objects quickly.
Instead this change makes EVP_AEAD_CTX large enough to contain the
AEAD-specific context inside itself. The dominant AEAD is AES-GCM, and
that's also the largest. So, in practice, this shouldn't waste too much
memory.
Change-Id: I795cb37afae9df1424f882adaf514a222e040c80
Reviewed-on: https://boringssl-review.googlesource.com/c/32506
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
This reverts https://boringssl-review.googlesource.com/24924. As noted
there, GCC 4.7 support ends 2018-03-23, which has passed. GCC 4.8.0 was
released 2013-03-22, so we are now past the five year mark, matching
Abseil's guidelines.
Abseil also now explicitly lists supported compilers and explicitly
requires GCC 4.8+. https://abseil.io/docs/cpp/platforms/platforms
gRPC also now requires 4.8 per
https://github.com/grpc/grpc/issues/10036#issuecomment-290248204
Update-Note: On the off chance someone was using GCC 4.7, which only
started working in January, that'll no longer work.
Change-Id: Ie017822e903f98293e7b5e9bda10f104f17be7b3
Reviewed-on: https://boringssl-review.googlesource.com/c/32564
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
If a startup process blocks, it's very useful to know which it was.
Change-Id: I04dd541695a61cfceb8142ea45d4bd5e3492c6ec
Update-note: updates internal bug 117227663.
Reviewed-on: https://boringssl-review.googlesource.com/c/32544
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This CL omits the RandTest.Fork unit test on Fuchsia, which does not
have fork(). Fuchsia has a bug (SEC-140) to create a suitable
replacement test.
Change-Id: Ic42f9149c24dc7321bfac1c718e9ecbb4a18b5d0
Reviewed-on: https://boringssl-review.googlesource.com/c/32504
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
As with sk_*, this. This doesn't fix the function pointer casts. Those
will be done in a follow-up change. Also add a test for lh_*_doall so we
cover both function pointer shapes.
Update-Note: This reworks how LHASH_OF(T) is implemented and also only
pulls in the definitions where used, but LHASH_OF(T) is never used
externally, so I wouldn't expect this to affect things.
Change-Id: I7970ce8c41b8589d6672b71dd03658d0e3bd89a7
Reviewed-on: https://boringssl-review.googlesource.com/c/32119
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This is consistent with the old behavior of d2i_*_fp and avoids tripping
Conscrypt's unnecessarily fragile error-handling (see
https://github.com/google/conscrypt/pull/552).
Additionally, by source inspection, CPython expects
ASN1_R_HEADER_TOO_LONG on EOF, analogously to PEM_R_NO_START_LINE. Fix
that. The other errors are a bit haphazard in the old implementation
(that code is really hard to follow), so I didn't match it too
carefully. In particular, OpenSSL would report ASN1_R_HEADER_TOO_LONG on
some generic tag parsing, but that is inconsistent with
ASN1_R_HEADER_TOO_LONG being an EOF signal.
Update-Note: https://boringssl-review.googlesource.com/32106 may have
caused some compatibility issues. This should fix it.
Change-Id: Idfe2746ffd7733de4338e14c58a40753e98a791e
Reviewed-on: https://boringssl-review.googlesource.com/c/32444
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Since clang-cl uses __udivti3 for __uint128_t division, linking div.obj
fails. Let me make div.c use BN_CAN_DIVIDE_ULLONG to decide using
__uint128_t division instead of BN_ULLONG.
Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=787617
Change-Id: I3ebe245f6b8917d59409591992efbabddea08187
Reviewed-on: https://boringssl-review.googlesource.com/c/32404
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
block128_f was recently changed to take an AES_KEY instead of a void*,
but AES_KEY is not defined in base.h. internal.h should not depend on
other sources to include aes.h for it.
Change-Id: I81aab5124ce4397eb76a83ff09779bfaea66d3c1
Reviewed-on: https://boringssl-review.googlesource.com/32364
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This CL changes adds a ".hidden OPENSSL_armcap_P" statement to the
".comm OPENSSL_armcap_P" statements for the sha*-armv8.pl files,
similar to what was doen for the sha*-armv4.pl files in CL 3471.
Change-Id: I524b3dce7e5cfe017498847fbf9b8a5df4b98fce
Reviewed-on: https://boringssl-review.googlesource.com/c/32324
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This removes the last mention of LHASH in public headers. This can only
break people who stack-allocate CONF or access the data field. The
latter does not happen (external code never calls lh_CONF_VALUE_*
functions). The former could not work as there would be no way to clean
it up.
Update-Note: CONF is now opaque.
Change-Id: Iad3796c4e75874530d7a70fde2f84a390def2d49
Reviewed-on: https://boringssl-review.googlesource.com/32118
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
The calls to qsort and bsearch are still invalid, but not avoidable
without reimplementing them. Fortunately, they cross libraries, so CFI
does not object.
With that, all that's left is LHASH!
Bug: chromium:785442
Change-Id: I6d29f60fac5cde1f7870d7cc515346e55b98315b
Reviewed-on: https://boringssl-review.googlesource.com/32114
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Unfortunately, some projects are calling into sk_pop_free directly, so
we must leave a compatibility version around for now.
Bug: chromium:785442
Change-Id: I1577fce6f23af02114f7e9f7bf2b14e9d22fa9ae
Reviewed-on: https://boringssl-review.googlesource.com/32113
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This fixes:
- Undefined function pointer casts.
- Missing X509_INFO_new malloc failure checks.
- Pointless (int) cast on strlen.
- Missing ERR_GET_LIB in PEM_R_NO_START_LINE check.
- Broken error-handling if passing in an existing stack and we hit a
syntax error.
Bug: chromium:785442
Change-Id: I8be3523b0f13bdb3745938af9740d491486f8bf1
Reviewed-on: https://boringssl-review.googlesource.com/32109
Reviewed-by: Adam Langley <agl@google.com>
This one is a little thorny. All the various block cipher modes
functions and callbacks take a void *key. This allows them to be used
with multiple kinds of block ciphers.
However, the implementations of those callbacks are the normal typed
functions, like AES_encrypt. Those take AES_KEY *key. While, at the ABI
level, this is perfectly fine, C considers this undefined behavior.
If we wish to preserve this genericness, we could either instantiate
multiple versions of these mode functions or create wrappers of
AES_encrypt, etc., that take void *key.
The former means more code and is tedious without C++ templates (maybe
someday...). The latter would not be difficult for a compiler to
optimize out. C mistakenly allowed comparing function pointers for
equality, which means a compiler cannot replace pointers to wrapper
functions with the real thing. (That said, the performance-sensitive
bits already act in chunks, e.g. ctr128_f, so the function call overhead
shouldn't matter.)
But our only 128-bit block cipher is AES anyway, so I just switched
things to use AES_KEY throughout. AES is doing fine, and hopefully we
would have the sense not to pair a hypothetical future block cipher with
so many modes!
Change-Id: Ied3e843f0e3042a439f09e655b29847ade9d4c7d
Reviewed-on: https://boringssl-review.googlesource.com/32107
Reviewed-by: Adam Langley <agl@google.com>
Lacking C++, this instead adds a mess of macros. With this done, all the
function-pointer-munging "_of" macros in asn1.h can also be removed.
Update-Note: A number of *really* old and unused ASN.1 macros were
removed.
Bug: chromium:785442
Change-Id: Iab260d114c7d8cdf0429759e714d91ce3f3c04b2
Reviewed-on: https://boringssl-review.googlesource.com/32106
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <alangley@gmail.com>
Debugging a POST failure when it prints nothing is painful. The
|check_test| helper already prints out information when it fails, but
some other paths were not handled. This change adds printfs for those
cases.
Change-Id: Ife71bb292a4f69679d0fa56686863aae9423e451
Updating-Note: updates internal bug 116469121
Reviewed-on: https://boringssl-review.googlesource.com/32145
Reviewed-by: David Benjamin <davidben@google.com>
Amazingly, this module didn't have a unit test yet.
Change-Id: I021bb83cc747174196958db14c97154f0574c2e8
Reviewed-on: https://boringssl-review.googlesource.com/32111
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
(Only in package names. Hyphens in file names are file.)
Change-Id: I80b705a780ffbad056abe7a7868d5682b30d2d44
Reviewed-on: https://boringssl-review.googlesource.com/32144
Commit-Queue: Matt Braithwaite <mab@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
BoringSSL depends on the platform's locking APIs to make internal global
state thread-safe, including the PRNG. On some single-threaded embedded
platforms, locking APIs may not exist, so this dependency may be disabled
with a build flag.
Doing so means the consumer promises the library will never be used in any
multi-threaded address space. It causes BoringSSL to be globally thread-unsafe.
Setting it inappropriately will subtly and unpredictably corrupt memory and
leak secret keys.
Unfortunately, folks sometimes misinterpreted OPENSSL_NO_THREADS as skipping an
internal thread pool or disabling an optionally extra-thread-safe mode. This is
not and has never been the case. Rename it to
OPENSSL_NO_THREADS_CORRUPT_MEMORY_AND_LEAK_SECRETS_IF_THREADED to clarify what
this option does.
Update-Note: As a first step, this CL makes both OPENSSL_NO_THREADS and
OPENSSL_NO_THREADS_CORRUPT_MEMORY_AND_LEAK_SECRETS_IF_THREADED work. A later CL
will remove the old name, so migrate callers after or at the same time as
picking up this CL.
Change-Id: Ibe4964ae43eb7a52f08fd966fccb330c0cc11a8c
Reviewed-on: https://boringssl-review.googlesource.com/32084
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Reason codes across libraries may collide. One must never check
ERR_GET_REASON without also checking ERR_GET_LIB.
Change-Id: I0b58ce27a5571ab173d231c1a673bce1cf0427aa
Reviewed-on: https://boringssl-review.googlesource.com/32110
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <alangley@gmail.com>
This format is kind of silly, but it seems not completely unused? Add a
basic test for it before I rewrite it to fix the function pointer casts.
Change-Id: Ib2d1563419b72cf468180b9cda4d13e216b7eb3a
Reviewed-on: https://boringssl-review.googlesource.com/32108
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <alangley@gmail.com>
It's a little bit shorter.
Change-Id: Ia1ba55d20ee4f2519a017871f5f5949081569e1a
Reviewed-on: https://boringssl-review.googlesource.com/32104
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
While I don't believe EINTR can occur with a non-blocking getrandom call
when talking to the kernel directly, that may not be true when certain
sandboxing systems are being used.
Additionally, with this change we will no longer silently ignore errors
other than ENOSYS.
Update-Note: update internal bug 115344138.
Change-Id: I952c132cf325dcc17dc38e68f054abc41de1f8b0
Reviewed-on: https://boringssl-review.googlesource.com/32006
Reviewed-by: David Benjamin <davidben@google.com>
David Benjamin
Adam Langley
Adam Langley
Nir Drucker
Steven Valdez
armfazh
Robert Sloan
Aaron Green
Yoshisato Yanagisawa
Matthew Braithwaite