Upstream merge 2024 04 11 #1527
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
samuel40791765
force-pushed
the
upstream-merge-2024-04-11
branch
3 times, most recently
from
090069e
to
3473c29
Compare
|
Some failures are occurring from |
samuel40791765
force-pushed
the
upstream-merge-2024-04-11
branch
2 times, most recently
from
c96788f
to
8e37989
Compare
torben-hansen
approved these changes
Apr 13, 2024
dkostic
approved these changes
Apr 16, 2024
samuel40791765
force-pushed
the
upstream-merge-2024-04-11
branch
2 times, most recently
from
319cd1a
to
2161a20
Compare
Change-Id: I8d1d3578e0e05757744b905689939708a9353e8d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64131 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> (cherry picked from commit df67e20de66fd95fd94b4d2837034a264f347c2c)
Although this is only used by <openssl/pem.h>, one existing caller expects the free functions to be defined in <openssl/x509.h>. It's not really worth it to put it in the other header, so just move it back. Change-Id: I7e719d51110b567296fcd797f72d13aa41de73af Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64287 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com> (cherry picked from commit 38c4bf10ce77ccabf50a61fb42edbad488ecffd8)
Other than the verify callback, these are practically unused. The one exception is that gRPC have used a couple of the CRL functions, though in somewhat questionable ways. Keep those for now, but we need to work with them to fix their code. There's also a bit of mess around check_issued, largely due to further rust-openssl misunderstandings. Update-Note: Removed a bunch of unused X509_STORE callback functions. We can restore them if someone was using them. Change-Id: I9c47581784c56a4c3b762e603a20ad7d5d612c65 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64133 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> (cherry picked from commit 998f511b9856281a6d8ec9617bf5a526740a88be)
There are quite a lot of these, and I haven't organized them into sections yet or anything, but get some easy ones. While I'm here, also do the check_private_key functions. They're pretty easy. Bug: 426 Change-Id: I1a5217d27908255833c350893bc3180ced82b0d0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64134 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> (cherry picked from commit 2ba7634b9e2b33875e2a40dec9e04abffe061f2c)
I'm getting tired of having to rederive the best way to convince the compiler to emit addc and subb functions. Do it once and use the Clang builtins when available, because compilers seem to generally be terrible at this. (See llvm/llvm-project#73847.) The immediate trigger was the FIPS 186-2 PRF, which completely doesn't matter, but reminded me of this mess. As far as naming and calling conventions go, I just mimicked the Clang ones. In doing so, also use the Clang builtins when available, which helps Clang x86_64 no-asm builds a bit: Before: Did 704 ECDH P-384 operations in 1018920us (690.9 ops/sec) Did 1353 ECDSA P-384 signing operations in 1077927us (1255.2 ops/sec) Did 1190 ECDSA P-384 verify operations in 1020788us (1165.8 ops/sec) Did 784 RSA 2048 signing operations in 1058644us (740.6 ops/sec) Did 34000 RSA 2048 verify (same key) operations in 1011854us (33601.7 ops/sec) Did 30000 RSA 2048 verify (fresh key) operations in 1005974us (29821.8 ops/sec) Did 7799 RSA 2048 private key parse operations in 1061203us (7349.2 ops/sec) Did 130 RSA 4096 signing operations in 1082617us (120.1 ops/sec) Did 10472 RSA 4096 verify (same key) operations in 1082857us (9670.7 ops/sec) Did 9086 RSA 4096 verify (fresh key) operations in 1039164us (8743.6 ops/sec) Did 2574 RSA 4096 private key parse operations in 1078946us (2385.7 ops/sec) After: Did 775 ECDH P-384 operations in 1008465us (768.5 ops/sec) Did 1474 ECDSA P-384 signing operations in 1062096us (1387.8 ops/sec) Did 1485 ECDSA P-384 verify operations in 1086574us (1366.7 ops/sec) Did 812 RSA 2048 signing operations in 1043705us (778.0 ops/sec) Did 36000 RSA 2048 verify (same key) operations in 1005643us (35798.0 ops/sec) Did 33000 RSA 2048 verify (fresh key) operations in 1028256us (32093.2 ops/sec) Did 10087 RSA 2048 private key parse operations in 1018067us (9908.0 ops/sec) Did 132 RSA 4096 signing operations in 1033049us (127.8 ops/sec) Did 11000 RSA 4096 verify (same key) operations in 1070502us (10275.6 ops/sec) Did 9812 RSA 4096 verify (fresh key) operations in 1047618us (9366.0 ops/sec) Did 3245 RSA 4096 private key parse operations in 1083247us (2995.6 ops/sec) But this is also a no-asm build, so we don't really care. Builds with assembly, broadly, do not use these codepaths. The exception is the generic ECC code on 32-bit Arm, which has a few mod-add functions, and we don't have 32-bit Arm bn_add_words assembly: Before: Did 168 ECDH P-384 operations in 1003229us (167.5 ops/sec) Did 330 ECDSA P-384 signing operations in 1076600us (306.5 ops/sec) Did 319 ECDSA P-384 verify operations in 1080750us (295.2 ops/sec) After: Did 195 ECDH P-384 operations in 1026458us (190.0 ops/sec) Did 350 ECDSA P-384 signing operations in 1005392us (348.1 ops/sec) Did 341 ECDSA P-384 verify operations in 1008486us (338.1 ops/sec) Change-Id: Ia3fa51e59398224b9c39180e1d856bb412aa1246 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64309 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> (cherry picked from commit 70ca6bc24be103dabd68e448cd3af29b929b771d)
Clang seems to be undoing the constant-time code here. This is another constant-time table lookup, so this is more of the usual problem. Found with the valgrind-based tooling. I didn't switch this to constant_time_conditional_memxor since we still haven't figured out https://crbug.com/boringssl/655, but we definitely need some kind of abstraction for this pattern. Change-Id: Ic11873b23cde31375ac1a326ed09ac1ca53ec913 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64310 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> (cherry picked from commit 4b9dd97dd7d2d8b0b34cfc9af446efa9b61118ee) Commit was changed to use OPENSSL_STATIC_ASSERT and crypto_word_t_is_too_small in AWS-LC.
The getter and setter are never used, largely because named parameters don't do anything. The field only exists for X509_VERIFY_PARAM_lookup, where we have to cast away const because the library expects to have to free the string. Just replace X509_VERIFY_PARAM_lookup with a handful of strcmp calls. As part of this, merge the pkcs7 and smime_sign entries. They were identical. Update-Note: Removed some unused functions. Change-Id: If4eaad52b50d28b83335f6b545af81063e0756d7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64135 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> (cherry picked from commit 790f96bdb549d4dd81a88f0a1fd2fe466b712d97)
Although new and free share a zero function, most of the function is irrelevant to both (either because we're about to free the object or have allocated it with zalloc), or only one of them. While I'm here, remove some unnecessary NULL checks guarding free functions. Change-Id: I9906ebc16c931f51b6341958bcf0a10426a1211b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64136 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> (cherry picked from commit 9d479673ccd027eaee60e4c382ed4a463d471a96)
The public headers are not yet merged. That will be doen in the subsequent CL. This required teaching make_errors.go that x509v3 are found elsewhere, also to skip irrelevant OPENSSL_DECLARE_ERROR_REASON calls. Change-Id: Ic40de51f9a5325acd60262c614924dc3407b800c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64137 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com> (cherry picked from commit 861cb31975b68abd0b6ed7d0dd37213b17385bab)
The headers moved from x509v3 to x509 was redone to avoid unintentionally taking changes we've skipped and keep AWS-LC specific changes. Change-Id: I53147d1f96d1f99909f5c8bda00cefb088677a0e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64138 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> (cherry picked from commit 58906eab928fe849a55cb846fcd84fb8b64773ed)
samuel40791765
force-pushed
the
upstream-merge-2024-04-11
branch
from
2161a20
to
cdc51f0
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes:
Merging from Upstream considering commits from google/boringssl@09febb3 (Nov 27, 2023) to google/boringssl@58906ea (Nov 30, 2023).
Call-outs:
See internal document for call outs.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.