Intel has made a late change to the AVX10 specification that removes
support for maximum vector lengths other than 512 bits. Therefore,
there won't be any such thing as AVX10/256. AVX10 will just be what was
originally planned to be called AVX10/512, effectively just
consolidating the AVX512 CPUID feature bits.
In light of this development and the fact that the 256-bit support in
aes-gcm-avx10-x86_64.pl didn't end up being used, the early adoption of
the "avx10", "avx10_256", and "avx10_512" names no longer makes sense.
So let's just use "avx512" instead.
Rename file names and function names accordingly, and update some
comments. No functional changes.
Change-Id: I2d59912b72d5ca0679b0ea54ae770a672ca36dea
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77847
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@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>
Since there is now a VAES+AVX2 implementation of AES-GCM, and the future
of AVX10/256 is uncertain, disable the AES-GCM functions that use
AVX10/256 (equivalently AVX512 with a maximum vector length of 256
bits). This leaves VAES+AVX2 as the sole 256-bit support for now.
For now this just affects Intel Ice Lake and Tiger Lake (which actually
support AVX512, but where downclocking issues make 256-bit arguably
preferable to 512-bit), where a slight performance loss is seen on long
messages. The following tables compare AES-256-GCM throughput in MB/s
on Ice Lake server for various message lengths:
Encryption:
| 16384 | 4096 | 4095 | 1420 | 512 | 500 |
--------+-------+-------+-------+-------+-------+-------+
Before | 7533 | 6990 | 6220 | 5096 | 4200 | 2702 |
After | 7403 | 6879 | 6236 | 4980 | 4040 | 2868 |
| 300 | 200 | 64 | 63 | 16 |
--------+-------+-------+-------+-------+-------+
Before | 2086 | 1555 | 1031 | 657 | 433 |
After | 2069 | 1635 | 1045 | 667 | 430 |
Decryption:
| 16384 | 4096 | 4095 | 1420 | 512 | 500 |
--------+-------+-------+-------+-------+-------+-------+
Before | 7703 | 7140 | 6524 | 5283 | 4244 | 2990 |
After | 7572 | 7056 | 6494 | 5155 | 4224 | 3073 |
| 300 | 200 | 64 | 63 | 16 |
--------+-------+-------+-------+-------+-------+
Before | 2276 | 1733 | 1070 | 680 | 447 |
After | 2249 | 1743 | 1100 | 692 | 447 |
This change should be reconsidered if AVX10/256 sees widespread support,
as we shouldn't carry forward a restriction to AVX2 unnecessarily.
This change also replaces gcm_init_vpclmulqdq_avx10 with
gcm_init_vpclmulqdq_avx10_512, now instantiated using 512-bit vectors.
Otherwise it would be the only avx10 function left using 256-bit.
Change-Id: I7fd21568482118a2ce7a382e9042b187cd2739f7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74369
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Add a VAES-optimized AES-GCM implementation that is optimized for AMD
Zen 3 processors, using AVX2 instead of AVX512 / AVX10. With AVX2 only
16 vector registers are available and some instructions are missing,
which is inconvenient and makes the code not easily sharable with the
AVX512 / AVX10 version. However, using VAES still gives a significant
performance improvement, about 80-85% on long messages as shown by the
following tables which show the change in AES-256-GCM throughput in MB/s
on a Zen 3 "Milan" processor for various message lengths in bytes.
Encryption:
| 16384 | 4096 | 4095 | 1420 | 512 | 500 |
--------+-------+-------+-------+-------+-------+-------+
Before | 3955 | 3749 | 3597 | 3054 | 2411 | 2038 |
After | 7128 | 6631 | 5975 | 4788 | 3807 | 2676 |
| 300 | 200 | 64 | 63 | 16 |
--------+-------+-------+-------+-------+-------+
Before | 1757 | 1405 | 856 | 602 | 356 |
After | 1885 | 1430 | 940 | 593 | 381 |
Decryption:
| 16384 | 4096 | 4095 | 1420 | 512 | 500 |
--------+-------+-------+-------+-------+-------+-------+
Before | 3962 | 3774 | 3593 | 2978 | 2510 | 1998 |
After | 7378 | 6836 | 6282 | 4826 | 3868 | 2753 |
| 300 | 200 | 64 | 63 | 16 |
--------+-------+-------+-------+-------+-------+
Before | 1742 | 1428 | 856 | 535 | 383 |
After | 1940 | 1534 | 940 | 573 | 383 |
Change-Id: I583dd6b48b81ab3c6df51bfe8729366cad500537
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74368
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@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>
On Arm, our CRYPTO_is_*_capable functions check the corresponding
preprocessor symbol. This allows us to automatically drop dynamic checks
and fallback code when some capability is always avilable.
This CL does the same on x86, as well as consolidates our
OPENSSL_ia32cap_P checks in one place. Since this abstraction is
incompatible with some optimizations we do around OPENSSL_ia32cap_get()
in the FIPS module, I've marked the symbol __attribute__((const)), which
is enough to make GCC and Clang do the optimizations for us. (We already
do the same to DEFINE_BSS_GET.)
Most x86 platforms support a much wider range of capabilities, so this
is usually a no-op. But, notably, all x86_64 Mac hardware has SSSE3
available, so this allows us to statically drop an AES implementation.
(On macOS with -Wl,-dead_strip, this seems to trim 35080 bytes from the
bssl binary.) Configs like -march=native can also drop a bunch of code.
Update-Note: This CL may break build environments that incorrectly mark
some instruction as statically available. This is unlikely to happen
with vector instructions like AVX, where the compiler could freely emit
them anyway. However, instructions like AES-NI might be set incorrectly.
Change-Id: I44fd715c9887d3fda7cb4519c03bee4d4f2c7ea6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51548
Reviewed-by: Adam Langley <agl@google.com>
These symbols were not marked OPENSSL_EXPORT, so they weren't really
usable externally anyway. They're also very sensitive to various build
configuration toggles, which don't always get reflected into projects
that include our headers. Move them to crypto/internal.h.
Change-Id: I79a1fcf0b24e398d75a9cc6473bae28ec85cb835
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50846
Reviewed-by: Adam Langley <agl@google.com>
The assembly dispatch tests currently assume NDEBUG is consistently
defined between C/C++ and assembly. While this is usually the case for
UNIX, CMake does not pass NDEBUG to NASM. This is giving gRPC some
difficulties in updating BoringSSL, so switch it to an opt-in
-DBORINGSSL_DISPATCH_TEST flag instead.
Update-Note: If you were copying NDEBUG over to assembly files, that's
no longer required (though it's harmless to leave it in). If you want to
run ImplDispatchTest.*, build both C/C++ and assembly with
-DBORINGSSL_DISPATCH_TEST in your debug builds. (Don't enable it in
release builds. It causes assembly to scribble in some globals.)
Change-Id: I9ab3371dc0f0a40b27b44ef93835e007a6346900
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37764
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This makes the AES_* functions meet our constant-time goals for
platforms where we have vpaes available. In particular, QUIC packet
number encryption needs single-block operations and those should have
vpaes available.
As a bonus, when vpaes is statically available, the aes_nohw_* functions
should be dropped by the linker. (Notably, NEON is guaranteed on
aarch64. Although vpaes-armv8.pl itself may take some more exploration.
https://crbug.com/boringssl/246#c4)
Bug: 263
Change-Id: Ie1c4727a166ec101a8453761757c87dadc188769
Reviewed-on: https://boringssl-review.googlesource.com/c/34875
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The first attempt involved using Linux's support for hardware
breakpoints to detect when assembly code was run. However, this doesn't
work with SDE, which is a problem.
This version has the assembly code update a global flags variable when
it's run, but only in non-FIPS and non-debug builds.
Update-Note: Assembly files now pay attention to the NDEBUG preprocessor
symbol. Ensure the build passes the symbol in. (If release builds fail
to link due to missing BORINGSSL_function_hit, this is the cause.)
Change-Id: I6b7ced442b7a77d0b4ae148b00c351f68af89a6e
Reviewed-on: https://boringssl-review.googlesource.com/c/33384
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Eric Biggers