Clarify that, on ARM/Aarch64, runtime feature detection is done only for Linux (including
Android) and Fuchsia. Reduce some of the duplication between Linux and Fuchsia; probably we should
do more later.
Previously the OpenSSL implementation was being used. Switch to the BoringSSL
version.
Switching to the BoringSSL implementation will make it easier to refactor the CPU feature
detection, which is important for upcoming ports.
This switch will also implicitly add support for BTI and pointer authentication for
Poly1305.
This is based on BoringSSL 63d06626d3a104868eee622e8e56d9f2dd643366.
Replace `GFp_bn_mul_add_word` with a clearer, simpler implementation.
The new `GFp_limbs_mul_add_limb` avoid explicit branches at the C code
level, unlike the code it replaces. (Obviously, even with the new
"branchless" code the compiler might be able to synthesize branches.)
Add the BoringSSL aes_nohw implementation with minimal changes needed to
build. Enable the AES-GCM AEAD tests for wasm32 targets gated on the "wasm_c"
feature.
Use the VPAES implementation from BoringSSL as of commit c556d87ddfe836294c8e04fc59d0c298951a4cc7,
with the 192-bit key handling and decryption removed.
Merge the VPAES and BSAES cases to VPAES_BSAES. Switch between the VPAES and BSAES implementation
on ARMv7 based on the amount of data being encrypted.
Clarify the dispatching logic in `ring::aead::aes`. In particular, avoid using `_` patterns
when matching on the result of `detect_implementation()`. Also rename Fallback to NOHW.
implementation.
*ring* tries to work without type-punning `memcpy`, so the use of that
in `GFp_gcm_ghash_nohw` was replaced by the use of `u64_from_be_bytes`.
This will (I hope) also help with the eventual support for big-endian
targets. Here's the diff from BoringSSL in that function:
```diff
-void gcm_ghash_nohw(uint64_t Xi[2], const u128 Htable[16], const uint8_t *inp,
- size_t len) {
+void GFp_gcm_ghash_nohw(uint64_t Xi[2], const u128 Htable[16], const uint8_t *inp,
+ size_t len) {
uint64_t swapped[2];
swapped[0] = CRYPTO_bswap8(Xi[1]);
swapped[1] = CRYPTO_bswap8(Xi[0]);
while (len >= 16) {
- uint64_t block[2];
- OPENSSL_memcpy(block, inp, 16);
- swapped[0] ^= CRYPTO_bswap8(block[1]);
- swapped[1] ^= CRYPTO_bswap8(block[0]);
+ swapped[0] ^= u64_from_be_bytes(&inp[8]);
+ swapped[1] ^= u64_from_be_bytes(inp);
gcm_polyval_nohw(swapped, &Htable[0]);
inp += 16;
len -= 16;
```
I also had to add a couple of (uint32_t) truncating casts where
BoringSSL expects an implicit truncation to occur, to avoid
`-Werror=conversion`.
During the merge, I found that `GFp_gcm_gmult_clmul` had its
`.cfi_startproc` on the wrong line. I fixed that as part of the merge.
During my review of the BoringSSL changes, I noticed that BoringSSL had
left some of the dead code in ghash-x86_64.pl, which had previously been
removed in *ring*. That removal is being done in BoringSSL in [1].
[1] https://boringssl-review.googlesource.com/c/boringssl/+/41144
This is a step towards removing the spin-rs dependency. `lazy_static!`'s
conditial use of spin-rs based on a feature flag was particularly problematic
because often other dependencies would enable that feature flag even in cases
where the `std::sync::Once` implementation was preferable.
spin-rs 0.5.2 fixes a bug in `rw_lock`. That bug doesn't seem to affect *ring* based
on the bug report and the fix PR, since *ring* uses only `spin::Once` and the fix
for the bug doesn't touch `spin::Once` at all. (I manually verified `spin::Once`
doesn't depend on `spin::rw_lock` at all.) Still, upgrade so that people don't get
scared and to avoid various inconveniences.
