Honestly, we don't actually need to support hashing more than 2**64
bytes on a single machine, so we certainly don't need to support 2**128
bytes. Thus pack these structures a little better by supporting only
2**96 bytes. This removes 8 bytes from these structures and thus 24
bytes from an HMAC_CTX.
It's possible to pack SHA-512 even tighter: the final byte of the block
buffer isn't used between calls. It can be repurposed to store the
buffer length (in the lower seven bits) and an "is SHA-384" flag in the
MSB. That saves another eight bytes.
But the same trick doesn't work for BLAKE2b because it hashes in a
"final block" flag and thus needs to know whether there's more data
coming before hashing a block. Thus it uses all 128 bytes for storage.
So while we can pack SHA-512 tighter, BLAKE2b would still keep
EVP_MAX_MD_DATA_SIZE the same.
Pleasingly, this seems net-positive on benchmarks. (Or, at least, not
negative.)
Before:
Did 49145000 SHA-512 (16 bytes) operations in 5000055us (9828891.9 ops/sec): 157.3 MB/s
Did 17905000 SHA-512 (256 bytes) operations in 5000134us (3580904.0 ops/sec): 916.7 MB/s
Did 5091000 SHA-512 (1350 bytes) operations in 5000183us (1018162.7 ops/sec): 1374.5 MB/s
Did 871000 SHA-512 (8192 bytes) operations in 5004110us (174056.9 ops/sec): 1425.9 MB/s
Did 440000 SHA-512 (16384 bytes) operations in 5008994us (87842.0 ops/sec): 1439.2 MB/s
After:
Did 50435000 SHA-512 (16 bytes) operations in 5000060us (10086879.0 ops/sec): 161.4 MB/s
Did 18218000 SHA-512 (256 bytes) operations in 5000068us (3643550.4 ops/sec): 932.7 MB/s
Did 5126000 SHA-512 (1350 bytes) operations in 5000588us (1025079.5 ops/sec): 1383.9 MB/s
Did 872000 SHA-512 (8192 bytes) operations in 5002028us (174329.3 ops/sec): 1428.1 MB/s
Did 440000 SHA-512 (16384 bytes) operations in 5004069us (87928.4 ops/sec): 1440.6 MB/s
Change-Id: Ib996d82cff3e959993a9e553a688766c2e9052fb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79508
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Speculative improvement for b/413675390, but there is insufficient
information in the bug to really be sure, and benchmarking does not seem
to give consistent results.
It seems that crypto_md32_* are not getting inlined when being built
with the NDK, which means we're not specializing by block size and we're
calling the block data functions indirectly. It's unclear what changed
here, as this code has been the same for a while. The root cause might
have been a compiler change.
Either way, switching to templates avoids tempting the compiler into
doing this, without the mess of macros that we had a while ago.
Inspecting the assembly, this seems to fix the codegen, but benchmarking
performance on my test device is very inconsistent.
Change-Id: Ib7c1e97d4d7a3e3b82a8cc5f0418b8b1100c330d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/78989
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
When we have both crypto/foo/internal.h and
crypto/fipsmodule/foo/internal.h, it's important that we put FIPSMODULE
into the header guard.
At that point, we probably should just put CRYPTO in there too, and
indeed we have been putting it in a few places. Go ahead and rewrite
them all with some clever shell scripting.
Change-Id: If61586f1d49ed477023530c36e9ed74373d4d1e6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77727
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
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>
This header used to supply CPU capability constants and things like
__ARM_MAX_ARCH__. The latter is now part of asm_base.h, automatically
included by everything, and assembly files no longer do capability
checks.
The immediate motivation was that there were a few misspelled includes
that used "openssl/arm_arch.h" instead of <openssl/arm_arch.h> (see
https://boringssl-review.googlesource.com/c/boringssl/+/76247), but
given we can just remove them anyway, may as well clear this out.
This now also means we don't pollute another prefix in the global
namespace (though external callers shouldn't have been using this header
anyway).
I've kept the header around, but a no-op, because some bindings
libraries have explicitly listed the header and it's probably not worth
the trouble to clear those out.
Bug: 42290548
Change-Id: I24f36cd48b0e3b6498ecbdc70fecc36961a8b9fe
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/76248
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
We use the standard Apache 2.0 file header, described in "APPENDIX: How
to apply the Apache License to your work."
This was primarily automated by running:
git ls-tree -r --name-only HEAD | xargs go run ./util/relicense.go
See go/boringssl-relicensing-triage for the results of triaging the
output of the tool.
As part of this, switch from taking fiat-crypto under MIT license to
Apache 2.0. (It is licensed under MIT OR Apache-2.0 OR BSD-1-Clause.)
The copyright_summary tool can also be used to confirm we didn't
accidentally drop any copyright lines:
# Run before the CL
git grep -l Copyright | xargs go run ./util/copyright_summary.go -out /tmp/old.json
# Run after the CL
git grep -l Copyright | xargs go run ./util/copyright_summary.go -compare /tmp/old.json
Bug: 364634028
Change-Id: I17c50e761e9d077a1f92e25969e50ed35e320c59
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75852
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Except for our public headers, our files no longer need to be consumed
by C. That means inline can just be inline, and with C++17,
OPENSSL_UNUSED can be [[maybe_unused]].
Bug: 42290600
Change-Id: Ibdb309bc413660e10d075fbb71d4d1dd87101c6d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74489
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Following the guidance in
https://opensource.google/documentation/reference/releasing/authors,
start maintaining an AUTHORS file.
Update all existing Google copyright lines to 'The BoringSSL Authors'
per the document. This CL also changes the styling to match the new
guidance: removed the '(c)' and the comma.
All other existing copyright lines are left unmodified. Going forward,
our preference will be that new contributions to BoringSSL use 'The
BoringSSL Authors', optionally adding to the AUTHORS file if the
contributor desires.
To avoid being presumptuous, this CL does *not* proactively list every
past contributor in the BoringSSL half of the AUTHORS file. Past
contributors are welcome to send us a patch to be added, or request that
we add you. (Listed or not, the commit log continues to be a more
accurate record, and any existing non-Google copyright lines were left
unmodified.)
The OpenSSL half of the AUTHORS file is seeded with the contents of the
current OpenSSL AUTHORS file, as of writing. The current contents in the
latest revision of the 1.1.1 branch
(b372b1f76450acdfed1e2301a39810146e28b02c) and master
(d992e8729ee38b082482dc010e090bb20d1c7bd5) are identical, just formatted
in text vs Markdown.
Note when reviewing: CONTRIBUTING.md and AUTHORS contain non-mechanical
changes.
Bug: 364634028
Change-Id: I319d0ee63ec021ad85e248e8e3304b9cf9566681
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74149
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This change switches nearly all of BoringSSL to use C++. The public
functions still use the C ABI, and so code written in C can still use
BoringSSL. Also the use of the C++ standard library is minimal and no
run-time requirement for it is intended.
Change-Id: I902d2f51a3c8d6bd0dc4aabe1b192a15d7b788e8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/72747
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Having the files named .c but included causes a ton of problems with
build systems. Many of our build systems care about three categories of
files:
- public headers, available to downstream targets
- source files, each of which is compiled as a compilation unit
- internal headers, not available to downstream targets
There is usually a check, in Bazel called layering_check that enforces
source files only include headers that are declared somewhere
appropriate. The bcm.c fragments, under this classification, are
internal headers.
However, in both GN and Bazel, internal headers and sources
both go in the source list. They are distinguished only by file
extension. When FIPS fragments have a .c file extension, they are
misinterpreted as source files, and many things break.
Rename them. Either .h and .inc would be sufficient. Because we had to
disable Bazel's parse_headers feature, there is no difference (AFAICT)
in their handling. Also, these files actually pass the parse_headers
feature, even though they don't have an include guard. Still, the tech
of the style guide suggests that .inc is probably the better file
extension.
https://google.github.io/styleguide/cppguide.html#Self_contained_Headers
I used .c.inc rather than plain .inc so that we can easily
rename them back to .c when we solve https://crbug.com/362530616.
Note that, as .inc is not as common of a file extension, people working
on BoringSSL may need to reconfigure their editors to map .inc to C/C++.
Update-Note: Some downstream builds have been working around this by
building the fragments individually and excluding bcm.c. This change
will break those workarounds but also remove the need for it. It should
now be consistently possible to build BoringSSL without modifying the
file list.
Bug: 362664827
Change-Id: I933115c37843317a066e24a1092728c9afce35f5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70689
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Strictly speaking this does not change any of the bcm/fipsmodule
code, it moves the tests out into libcrypto so that once we move
to an api boundary where bcm does not call libcrypto functions
directly, these tests still can do so.
Bug: 722
Change-Id: I9defc70a9e523e52dda2d53ab4bd155a4b44fc02
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68787
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
We've made crypto/internal.h require SSE2 support for a few months now
without much fuss. Finish the job and remove the fallback paths. We've
never tested any of these paths, and this removes a slew of
OPENSSL_ia32cap_P references from the assembly.
Bug: 673
Change-Id: I446a033d132af5038ab427b8560cbf20c1d97335
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68207
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
1) We are calling sha1_block_data_order_avx when avx2 is enabled
We should be calling sha1_block_data_order_avx2
2) Looks like clang doesn't define __BMI1__ and calls it simply
__BMI__, see https://godbolt.org/z/s8anxn9rc
This is less of an issue since we will fallback to dynamic dispatch
anyway.
Change-Id: I9821405444c2e39167f1423c5f08bfcbca1efa51
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66827
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This took a little restructuring because they were previously all one
big function. Some notes:
- label() and set_label() in x86 perlasm default to function-scoped. But
static_label() marks a label as file-scoped, which is why "pic_point"
and "K256" work.
- There's a pretty sizeable common preamble. I just copied it to each
for simplicity. I'm pretty sure some of it is wasted, but it's
definitely not all wasted, between loading parameters, setting up
stack alignment, and saving the old stack location. But I'm not sure
if all those 16 bytes are actually used.
Bug: 673
Change-Id: I6e8671d05d07cb4676ecf117dd56e2ed355c5d19
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65874
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Historically, OPENSSL_ia32cap_P used reserved bit 20 to trigger some
variation in the RC4 implementation. That same bit was used in
upstream's f889bb03841c69330d1e14a873c9982d3702f2d0 to disable some
optimization on the Pentium 4.
We've long since always cleared that flag (see cpu_intel.c), so this is
dead code. Remove it.
Change-Id: Ib9c0d88235617941833eb8aabb17a4713bdf6606
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65873
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This is a reland of
https://boringssl-review.googlesource.com/c/boringssl/+/64749, which was
reverted in
https://boringssl-review.googlesource.com/c/boringssl/+/65328 due to
issues in Arm mode (i.e. not Thumb mode) builds that target Armv6+
instead of Armv7+.
The issue was that sha256_block_data_order_nohw has slightly different
sizes depending on __ARM_ARCH. Prior to moving the dispatch, the sizes
worked out such that they were always encodable in ADR. After moving the
dispatch, the instructions got shorter, such that the Armv7+ build still
worked, but the Armv6+ build needed to encode an offset of 0x1060
(previously 0x1080), which does not fit.
See https://alisdair.mcdiarmid.org/arm-immediate-value-encoding/ for
details on Arm's very fussy immediate value encoding. It's not the only
form used for ADR (Thumb2 works very differently), but it's the
applicable one here.
While we could shuffle things around, this is all far too fragile. Just
use the LDR; ADD pattern we used for the other function. ADRL would
avoid a load (it splits the offset into two constants without a constant
bank), but that's a pseudo-instruction that's only supported by gas.
clang-assembler didn't want to implement it. Android have a macro at
https://android.googlesource.com/platform/ndk/+/refs/heads/master/docs/ClangMigration.md#arm,
but it didn't work for me when I tried it. Also, searching around, it
sounds like ADRL in gas only works in Arm mode and not Thumb mode?
We could probably work through all that, but the compiler emits constant
banks on 32-bit Arm all the time. (I got this pattern from Clang's
output.) This is probably not worth the trouble.
Bug: 673
Change-Id: I165544764a931b293aa66fb3fc9bb8f01eeb8092
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65808
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
sha256_block_data_order_hw required a bit of wrestling with Arm
immediate limits. PC-relative addressing in 32-bit Arm is a huge mess.
I think I could have avoided the extra load with a lot of effort
(convincing the assembler to evaluate a messy expression), but this is
simpler and there was no measurable performance difference.
Change-Id: I3fab4abc0fa24e0d689581e2c9b9faaa32bd7442
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64749
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
It's 2023. We shouldn't need to be counting offsets from PC anymore.
Instead, let the assembler figure this out with an ADR instruction.
Additionally, since it's easy, in chacha-armv4.pl, avoid depending on
the exact offset between code and data. We still depend on the code and
data being close enough to fit within ADR's (very tight) bounds however.
(E.g. an ADR of K256 inside sha256_block_data_order_armv8 would not work
because K256 is too far away.)
I have not removed the offset dependency in the SHA-2 files yet as
they're a bit thorny and .Lsha256_block_data_order-K256 does not seem to
work on Apple's 32-bit Arm assembler. (We probably should drop 32-bit
Arm assembly on Apple platforms. It doesn't really exist anymore.) Once
the armcap references are gone, that will be more straightforward.
Update-Note: If 32-bit Arm assembly no longer builds, let us know and
tell us what your toolchain is.
Change-Id: Ie191781fed98d53c3b986b2f535132b970d79f98
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64747
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
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 https://github.com/llvm/llvm-project/issues/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>
Since ACLE is now widely implemented, just use the standard one. I've
left a TODO with __ARM_MAX_ARCH__. Probably should just remove that one?
Also deduplicate some code between arm_arch.h and asm_base.h. I think I
meant to move it to asm_base.h and didn't finish the job?
Change-Id: I85bb3160ec64acdabd11d741f1958ff56199c4c7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63525
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
sha512-armv8.pl and sha512-x86_64.pl implement both SHA-256 and SHA-512
and select which to emit by looking for "512" in the output path.
This can result in a false positive if the output path happens to
contain "512" in it. When the build uses relative paths, it's fine, but
this seems needlessly fragile. If we're generate into a temporary file,
there's a small but non-negligible probability that the path has a
"512" in it.
Instead, give those scripts three arguments: flavor hash output, so the
selection is independent of the output file name.
Bug: 542
Change-Id: Idf256abed1c07003034d3eb4544552125e3289e5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62325
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
GCC does not have __has_feature, so writing #if __has_feature(foo),
without a guard, will cause GCC to error. This is tripping the gRPC
update.
Prior to https://boringssl-review.googlesource.com/c/boringssl/+/60765,
this worked because the preamble to every assembly file would define the
missing __has_feature macro as part of detecting MSan. Now we pick up
the logic in <openssl/base.h>, which tries not to stomp over symbols we
don't own. This had the side effect of removing the __has_feature
polyfill.
Though "public", <openssl/asm_base.h> is not really a public header, so
we could put the __has_feature polyfill in there. But we already have a
pattern for detecting sanitizers in <openssl/target.h>, so just switch
to that one.
Change-Id: I747b4513f1b2f189d2df629149f22fd0fa490257
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61565
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This allows operating systems to insist on IBT
enforcement as an exploit mitigation mechanism without
needing to make an exception for anything using a
bundled boringssl, such as chrome, mono, and qtwebengine.
Change-Id: Iac28dd3d2af177b89ffde10ae97bce23739feb94
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60625
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Various constants and strings identifying the authors are currently
misplaced in .text. This change allows using execute-only .text on
platforms that enforce it by default, such as OpenBSD.
Modify x86_64-xlate.pl to replace .rodata with __DATA,__const for macs.
Adapt the nasm/masm path to emit an .rdata segment with alignment of 8.
This last change is not strictly needed but makes things explicit.
Change-Id: If716b892c1faabd85c6c70bdd75e145304841f83
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57445
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We no longer have a need to support ppc64le, nor do we have any testing
story for the assembly we previously had. Remove all ppc64le-specific
assembly.
This CL stops short of removing it from base.h. That'll be done in a
follow-up CL, just to separate which removals are for the assembly and
which removals remove all support.
Update-Note: After this change, ppc64le builds drop assembly
optimizations and will fallback to a generic C-based AES implementation.
Change-Id: Ic8075638085761d66cebc276eb16c4770ce03920
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56388
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
GCC 12's -Wstringop-overflow flags issues in SHA224_Final, etc., because
it calls into generic code that might output a SHA-224 length or a
SHA-256 length, and the function prototype declares the array is only
sized for SHA-224.
This is a bit messy because OpenSSL's API for the truncated SHA-2 hashes
allows you to mix and match them. The output size is set by SHA224_Init
and then, originally, SHA256_Final and SHA224_Final were the same thing.
See how OpenSSL's own SHA224 function calls SHA224_Init + SHA256_Final:
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1q/crypto/sha/sha256.c#L49-L61
To get the function prototype bounds to work out, we tightened this
slightly in
https://boringssl-review.googlesource.com/c/boringssl/+/47807 and added
an assert to SHA224_Final that ctx->md_len was the right size.
SHA256_Final does not have that assert yet. The assert says that mixing
SHA256_Init and SHA224_Final is a caller error.
This isn't good enough for GCC 12, which checks bounds assuming there is
no external invariant on ctx->md_len. This CL changes the behavior of
the shorter Final functions: they will now always output the length
implied by the function name. ctx->md_len only figures into an assert()
call. As we don't have the assert in the untruncated functions yet, I've
preserved their behavior, but the test run with cl/471617180 should tell
us whether apply this to all functions is feasible.
Update-Note: Truncated SHA-2 Final functions change behavior slightly,
but anyone affected by this behavior change would already have tripped
an assert() in debug builds.
Change-Id: I80fdcbe6ad76bc8713c0f2de329b958a2b35e8ae
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54246
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Adam Langley