Cherry-pick BoringSSL changes through 808b8f3b9d71a055f741d5f7338d206e98747950. #2483
+324
−543
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
aes-gcm-avx10-x86_64.pl: fold _ghash_mul_step into _ghash_mul Fold _ghash_mul_step into _ghash_mul, since the support for interleaving a single-vector GHASH multiplication with other instructions is not used. It is used in the Linux port (for _aes_gcm_final), but it is not used in the BoringSSL port. No change to the generated assembly code. Change-Id: I5a65ee490e814ca6390c4b968ab135091c344a98 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77167 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
aes-gcm-avx10-x86_64.pl: use strict mode and sync with avx2 code Make aes-gcm-avx10-x86_64.pl run in perl's strict mode, like aes-gcm-avx2-x86_64.pl does. Also bring in some of the other non-functional changes to the perl code in the avx2 version, like naming V0-V3 as AESDATA0-AESDATA3 in the en/decryption function. No change to the generated assembly code except whitespace. Change-Id: I5857cfdcc881a34c971959a1962dfb181eb11450 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77168 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
Use vmovdqa to save/restore xmm registers in AES-GCM code on Windows The Windows xmm register save/restore code generated by aes-gcm-avx2-x86_64.pl and aes-gcm-avx10-x86_64.pl used movdqa, which is a legacy SSE instruction. This was functionally correct, but it was the only use of legacy SSE instructions in these files. Since these files contain AVX code, use the VEX encoded forms of these instructions instead. They are not any longer (in fact they're one byte shorter for xmm8 and higher), and they have the added bonus of not having their performance be dependent on whether other code executed vzeroupper. Change-Id: Ib41ae1097d30d88dfcd4c68c0e850104034a5646 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77228 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
Stop manually encoding a bunch of x86-64 instructions The perlasm code used to manually encode some instructions, presumably to accomodate older assemblers that don't recognize them. The newest of these (SHA instructions) seem to have been added in binutils 2.24, released in 2013. Remove the transforms so we don't have to worry about bugs in some ad-hoc perl code. I confirmed this was equivalent by comparing the output of `objdump -d` on the assembled object files. This revealed one issue in the xlate script where it tried to suffix rdrand, which is apparently unsuffixable. Change-Id: I51377e38ec06b099e730da29b85743188abf9723 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77388 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> Auto-Submit: David Benjamin <davidben@google.com>
Remove unused "endbranch" x86-64 encoder There is no such instruction as endbranch. It's endbr64. That was added to binutils in 2.29. That is past our five year policy anyway, though I think we've only exercised that recently with VPCLMULQDQ. But this is moot because we do CET differently from OpenSSL anyway and use the _CET_ENDBR macro from <cet.h>. I think we can reasonably assume that anyone building with __CET__ has a new enough assembler that supports endbr64. If we ever decide to do CET by always encoding the special NOP, as OpenSSL does, we may need to go back and reencode things, but by then it will be even less likely that we need to help the assembler out. Change-Id: I3c9890810c5621f317cb5ecca5cbd8537cca0fe7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77389 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> Auto-Submit: David Benjamin <davidben@google.com>
bn: Change return type of `bn_mul_mont_*` internals to `void`. Change-Id: Id8be6697df6a6f6613105c67c96250cc084595b2 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75647 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
Decrease BN_MONTGOMERY_MAX_WORDS to 16384 bits I'm not sure where I got the original value (I think it was when I was trying to set a limit for all of BIGNUM) but 8 KiB is still a fairly large stack allocation. I also missed that some of the bn_mul_mont implementations seem to alloca 2 * num words, so that's actually 16 KiB of stack used. We only support up to 16384-bit RSA, so we only need BN_MONT_CTX to work with that. Lower the limit accordingly. Ideally we'd get down to 8192 (see crbug.com/402677800). While we have to allow giant BIGNUMs for some non-cryptography callers, this means that Montgomery reduction and all the cryptography code can assume one integer fits in 2 KiB (lowering the RSA limit could bring us down to 1 KiB). I'm hoping this is small enough that all our Montgomery multiplication codepaths can just stack-allocate their temporaries. (We already believe it's small enough for bn_mul_mont, just other codepaths still allocate.) That should remove the main load-bearing use of BN_CTX. Update-Note: BN_MONT_CTX now only works for 16834-bit moduli or lower. This has no impact on cryptographic primitives supported by BoringSSL, which were already capped at that size. Bug: 42290433, 402677800 Change-Id: Iaaf8ba34eabeb3b90f4219e0faa5b74c4b1de4b8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77507 Reviewed-by: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2483 +/- ##
=======================================
Coverage 96.60% 96.61%
=======================================
Files 180 180
Lines 21820 21820
Branches 539 539
=======================================
+ Hits 21080 21081 +1
Misses 623 623
+ Partials 117 116 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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.
Note that b1ef5eee90d8748d5273fa3e6bb618dd4f925135 was done in #2470.