Our old redirectors were emitting code to call their target functions normally.
However, the PPC ABI expects callers to set up parameter save areas for their
callees, notably if the target is a varargs function.
Instead, mimic the pattern used when calling an external function or function
pointer and avoid touching the stack.
Change-Id: Ia28c9d2b82fcd99c4a2f70f5f587d0e0463a6f0e
Reviewed-on: https://boringssl-review.googlesource.com/17284
Reviewed-by: Adam Langley <agl@google.com>
The pointer and length fields should always be kept in sync. Other code
already assumes this anyway.
Change-Id: I62bc77b805cd4d81f2caa4aa49ad3e9d96faa25e
Reviewed-on: https://boringssl-review.googlesource.com/17306
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>
786793411a only got applied to one of the
setters way back.
Change-Id: Ib798002d5ab7a3d0599b6520af25897949fb0071
Reviewed-on: https://boringssl-review.googlesource.com/17305
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
There was a typo there. Also the document's title capitalizes "64-Bit"
and "V2" funny.
Change-Id: I38a7f8d575ce2bb48dcc2ce5a4d683a7a170db87
Reviewed-on: https://boringssl-review.googlesource.com/17268
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Avoid dealing with that function call everywhere.
Change-Id: I7de64b59c8d17e8286c18a6b20c704e8ba8b9ebe
Reviewed-on: https://boringssl-review.googlesource.com/17267
Reviewed-by: Steven Valdez <svaldez@google.com>
These are not the true version filters due to SSL_OP_NO_* filters.
Change-Id: I4c2db967d885f7c1875a3e052c5b02ea8d612fe1
Reviewed-on: https://boringssl-review.googlesource.com/17266
Reviewed-by: Steven Valdez <svaldez@google.com>
The original motivation behind the sign/complete split was to avoid
needlessly hashing the input on each pass through the state machine, but
we're payload-based now and, in all cases, the payload is either cheap
to compute or readily available. (Even the hashing worry was probably
unnecessary.)
Tweak ssl_private_key_{sign,decrypt} to automatically call
ssl_private_key_complete as needed and take advantage of this in the
handshake state machines:
- TLS 1.3 signing now computes the payload each pass. The payload is
small and we're already allocating a comparable-sized buffer each
iteration to hold the signature. This shouldn't be a big deal.
- TLS 1.2 decryption code still needs two states due to reading the
message (fixed in new state machine style), but otherwise it just
performs cheap idempotent tasks again. The PSK code is reshuffled to
guarantee the callback is not called twice (though this was impossible
anyway because we don't support RSA_PSK).
- TLS 1.2 CertificateVerify signing is easy as the transcript is readily
available. The buffer is released very slightly later, but it
shouldn't matter.
- TLS 1.2 ServerKeyExchange signing required some reshuffling.
Assembling the ServerKeyExchange parameters is moved to the previous
state. The signing payload has some randoms prepended. This is cheap
enough, but a nuisance in C. Pre-prepend the randoms in
hs->server_params.
With this change, we are *nearly* rid of the A/B => same function
pattern.
BUG=128
Change-Id: Iec4fe0be7cfc88a6de027ba2760fae70794ea810
Reviewed-on: https://boringssl-review.googlesource.com/17265
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Change-Id: Ic2eae037d50de4af67f6cbe888e16d507ab674d8
Reviewed-on: https://boringssl-review.googlesource.com/17224
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>
It does not appear removing support for these is feasible right now. :-(
Change-Id: I99521ba6c141855b5140d98bce445d7e62415661
Reviewed-on: https://boringssl-review.googlesource.com/17251
Reviewed-by: David Benjamin <davidben@google.com>
We've got an asynchronous ServerKeyExchange state in the middle that
complicates things a bit, but this is still a little tighter.
BUG=128
Change-Id: I4ee2e3b85e677c9555d2fbddd387c12d41ab2b54
Reviewed-on: https://boringssl-review.googlesource.com/17250
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
We can take advantage of our flight-by-flight model.
BUG=128
Change-Id: If27a5b6d88055da71199ef672d9c71969925aca9
Reviewed-on: https://boringssl-review.googlesource.com/17249
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Although Microsoft does not support building with /Wall, starting
VS2017, they provide a way to suppress warnings only in STL code. This
lets us keep some warnings active on our code while disabling them in
the STL.
https://blogs.msdn.microsoft.com/vcblog/2017/02/06/stl-fixes-in-vs-2017-rtm/
We currently still support VS2015, so we can't switch most of our
suppressions to this, but anything which applies only to VS2017 and up
will work.
Change-Id: I5f6d621dd1dbc060e09bded776d1714785a63147
Reviewed-on: https://boringssl-review.googlesource.com/17245
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>
Bug: chromium:731280
Change-Id: I87161a3400ac5119401ec157df5843249971327a
Reviewed-on: https://boringssl-review.googlesource.com/17246
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Aaron Green <aarongreen@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Free code coverage. Also rename things in SSL_select_next_proto so it
works for NPN and ALPN. (I found some code which uses it for ALPN.)
Change-Id: I8d06b768f9484dc3eda1a20506ec84ec3ddbc883
Reviewed-on: https://boringssl-review.googlesource.com/17206
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: Ice03a4e8378da8ab94f1aa0545615c8aee6982d7
Reviewed-on: https://boringssl-review.googlesource.com/17204
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>
BUG=76
Change-Id: If58a73da38e46549fd55f84a9104e2dfebfda43f
Reviewed-on: https://boringssl-review.googlesource.com/14164
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: 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>
This doesn't hugely matter, but I noticed it was some missing coverage.
Change-Id: I3e425d47fbbeaacd9da2ae883f34e89b4562ec11
Reviewed-on: https://boringssl-review.googlesource.com/17184
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: I8512c6bfb62f1a83afc8f763d681bf5db3b4ceae
Reviewed-on: https://boringssl-review.googlesource.com/17144
Commit-Queue: Adam Langley <alangley@gmail.com>
Reviewed-by: David Benjamin <davidben@google.com>
This change allows blinding to be disabled without also having to remove
|e|, which would disable the CRT and the glitch checks. This is to
support disabling blinding in the FIPS power-on tests.
(Note: the case where |e| isn't set is tested by RSATest.OnlyDGiven.)
Change-Id: I28f18beda33b1687bf145f4cbdfd37ce262dd70f
Reviewed-on: https://boringssl-review.googlesource.com/17146
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Three modules were left behind in
I59df0b567e8e80befe5c399f817d6410ddafc577.
(Imported from upstream's c93f06c12f10c07cea935abd78a07a037e27f155.)
This actually meant functions defined in those two files were
non-functional. I'm guessing no one noticed upstream because, if you go
strictly by iOS compile-time capabilities, all this code is unreachable
on ios32, only ios64.
Change-Id: I55035edf2aebf96d14bdf66161afa2374643d4ec
Reviewed-on: https://boringssl-review.googlesource.com/17113
Reviewed-by: David Benjamin <davidben@google.com>
(Imported from upstream's 413b6a82594ab45192dda233a77efe5637d656d6.)
This doesn't affect us but is imported to make future imports easier.
Change-Id: I8cc97d658df6cc25da69bff840b96a47e2946ddb
Reviewed-on: https://boringssl-review.googlesource.com/17112
Reviewed-by: Adam Langley <agl@google.com>
This change was made by copying over the files as of that commit and
then discarding the parts of the diff which corresponding to our own
changes.
Change-Id: I28c5d711f7a8cec30749b8174687434129af5209
Reviewed-on: https://boringssl-review.googlesource.com/17111
Reviewed-by: Adam Langley <agl@google.com>
Close difference gap on Cortex-A9, which resulted in further improvement
even on other processors.
(Imported from upstream's 8eed3289b21d25583ed44742db43a2d727b79643.)
Performance numbers on a Nexus 5X in AArch32 mode:
$ ./bssl.old speed -filter RSA -timeout 5
Did 355 RSA 2048 signing operations in 5009578us (70.9 ops/sec)
Did 20577 RSA 2048 verify operations in 5079000us (4051.4 ops/sec)
Did 66 RSA 4096 signing operations in 5057941us (13.0 ops/sec)
Did 5564 RSA 4096 verify operations in 5086902us (1093.8 ops/sec)
$ ./bssl speed -filter RSA -timeout 5
Did 411 RSA 2048 signing operations in 5010206us (82.0 ops/sec)
Did 27720 RSA 2048 verify operations in 5048114us (5491.2 ops/sec)
Did 86 RSA 4096 signing operations in 5056160us (17.0 ops/sec)
Did 8216 RSA 4096 verify operations in 5048719us (1627.3 ops/sec)
Change-Id: I8c5be9ff9405ec1796dcf4cfe7df8a89e5a50ce5
Reviewed-on: https://boringssl-review.googlesource.com/17109
Reviewed-by: Adam Langley <agl@google.com>
As some of ARM processors, more specifically Cortex-Mx series, are
Thumb2-only, we need to support Thumb2-only builds even in assembly.
(Imported from upstream's 11208dcfb9105e8afa37233185decefd45e89e17.)
Change-Id: I7cb48ce6a842cf3cfdf553f6e6e6227d52d525c0
Reviewed-on: https://boringssl-review.googlesource.com/17108
Reviewed-by: Adam Langley <agl@google.com>
This reverts commit 2cd63877b5. We've
since imported a change to upstream which adds some #defines that should
do the same thing on clang. (Though if gas accepts unified assembly too,
that does seem a better approach. Ah well. Diverging on these files is
expensive.)
This is to reduce the diff and make applying some subsequent changes
easier.
Change-Id: I3f5eae2a71919b291a8de9415b894d8f0c67e3cf
Reviewed-on: https://boringssl-review.googlesource.com/17107
Reviewed-by: Adam Langley <agl@google.com>
(Imported from upstream's 5e5ece561d1f7e557c8e0ea202a8c1f3008361ce.)
This doesn't matter but reduces the diff for changes past it.
Change-Id: Ib2e979eedad2a0b89c9d172207f6b7e610bf211f
Reviewed-on: https://boringssl-review.googlesource.com/17106
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>
We patch arm-xlate.pl to add the ifdefs, so this isn't needed and
reduces our upstream diff.
(We do still have a diff from upstream here. Will go through them
shortly.)
Change-Id: I5b1e301b9111969815f58d69a98591c973465f42
Reviewed-on: https://boringssl-review.googlesource.com/17105
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>
This imports upstream's scrypt implementation, though it's been heavily
revised. I lost track of words vs. blocks vs. bigger blocks too many
times in the original code and introduced a typedef for the fixed-width
Salsa20 blocks. The downside is going from bytes to blocks is a bit
trickier, so I took advantage of our little-endian assumption.
This also adds an missing check for N < 2^32. Upstream's code is making
this assumption in Integerify. I'll send that change back upstream. I've
also removed the weird edge case where a NULL out_key parameter means to
validate N/r/p against max_mem and nothing else. That's just in there to
get a different error code out of their PKCS#12 code.
Performance-wise, the cleanup appears to be the same (up to what little
precision I was able to get here), but an optimization to use bitwise
AND rather than modulus makes us measurably faster. Though scrypt isn't
a fast operation to begin with, so hopefully it isn't anyone's
bottleneck.
This CL does not route scrypt up to the PKCS#12 code, though we could
write our own version of that if we need to later.
BUG=chromium:731993
Change-Id: Ib2f43344017ed37b6bafd85a2c2b103d695020b8
Reviewed-on: https://boringssl-review.googlesource.com/17084
Reviewed-by: Adam Langley <agl@google.com>
Rather than adding a new mode to EVP_PKEY_CTX, upstream chose to tie
single-shot signing to EVP_MD_CTX, adding functions which combine
EVP_Digest*Update and EVP_Digest*Final. This adds a weird vestigial
EVP_MD_CTX and makes the signing digest parameter non-uniform, slightly
complicating things. But it means APIs like X509_sign_ctx can work
without modification.
Align with upstream's APIs. This required a bit of fiddling around
evp_test.cc. For consistency and to avoid baking details of parameter
input order, I made it eagerly read all inputs before calling
SetupContext. Otherwise which attributes are present depend a lot on the
shape of the API we use---notably the NO_DEFAULT_DIGEST tests for RSA
switch to failing before consuming an input, which is odd.
(This only matters because we have some tests which expect the operation
to abort the operation early with parameter errors and match against
Error. Those probably should not use FileTest to begin with, but I'll
tease that apart a later time.)
Upstream also named NID_Ed25519 as NID_ED25519, even though the
algorithm is normally stylized as "Ed25519". Switch it to match.
Change-Id: Id6c8f5715930038e754de50338924d044e908045
Reviewed-on: https://boringssl-review.googlesource.com/17044
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
On POWER, r0 is wired to zero in some argument positions of some
instructions. The base register for a load is one of them. Thus, if
rewriting a load to r0, we cannot use r0 to store the base address.
This could be more efficient, but loading to r0 appears to be very rare
so I'm not going to worry about it for now.
Change-Id: I14dac96ba4c0380b166a7667b0cba918f1ae25ec
Reviewed-on: https://boringssl-review.googlesource.com/17065
Commit-Queue: Adam Langley <agl@google.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>
These behave like EVP_AEAD_CTX_{seal,open} respectively, but receive
ciphertext and authentication tag as separate arguments, rather than one
contiguous out or in buffer.
Change-Id: Ia4f1b83424bc7067c55dd9e5a68f18061dab4d07
Reviewed-on: https://boringssl-review.googlesource.com/16924
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
These are never referenced within the library or externally. Some of the
constants have been unused since SSLeay.
Change-Id: I597511208dab1ab3816e5f730fcadaea9a733dff
Reviewed-on: https://boringssl-review.googlesource.com/17025
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
https://boringssl-review.googlesource.com/c/12360/ made us define
BORINGSSL_SHARED_LIBRARY when building tests via Bazel. The test has now
been moved to crypto_test, where the flags are more easily under the
control of the consumer.
Change-Id: If237efca219a1f03d64dc801cc1d585556bf2d1d
Reviewed-on: https://boringssl-review.googlesource.com/16987
Reviewed-by: David Benjamin <davidben@google.com>
We've been compile-testing it for some time, and now we have a path (by
way of GTest and Chromium) to get them test coverage.
Change-Id: Ic33be8fce4bbef10cd586428e74972f230525792
Reviewed-on: https://boringssl-review.googlesource.com/16990
Reviewed-by: Kári Helgason <kthelgason@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
None of these declarations are ever defined or constants used.
Change-Id: Id71ed5f02f9972d375845eacd9ce290a64b1c525
Reviewed-on: https://boringssl-review.googlesource.com/17024
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Originally we had some confusion around whether the features could be
toggled individually or not. Per the ARM C Language Extensions doc[1],
__ARM_FEATURE_CRYPTO implies the "crypto extension" which encompasses
all of them. The runtime CPUID equivalent can report the features
individually, but it seems no one separates them in practice, for now.
(If they ever do, probably there'll be a new set of #defines.)
[1] http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf
Change-Id: I12915dfc308f58fb005286db75e50d8328eeb3ea
Reviewed-on: https://boringssl-review.googlesource.com/16991
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>
These are, in turn, just taken from RFC 8032 and are all in
ed25519_tests.txt. But it's probably good to test non-empty inputs at
the EVP_PKEY layer too.
Change-Id: I21871a6efaad5c88b828d2e90d757c325a550b2a
Reviewed-on: https://boringssl-review.googlesource.com/16989
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
