Revert the names used in the BoringSSL C/asm code to the names used in
BoringSSL. This substantially reduces the diff between *ring* and
BoringSSL for these files.
Use a variant of BoringSSL's symbol prefixing machinery to semi-
automatically prefix FFI symbols with the `GFp_` prefix. The names aren't
all exactly the same as before, because previously we *replaced* a
symbol's original prefix with the `GFp_` prefix; now we're prepending
`GFp_`. In the future we'll use a different prefix entirely.
This paves the way for using different prefixes for each version so that
multiple versions of *ring* can be linked into an executable at once.
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
When running the ARM perlasm files on Windows, close STDOUT fails. There
appears to be some weird quirk on Windows when one replaces STDOUT with
a pipe. The x86_64.pl files all avoid this by opening OUT and then
setting *STDOUT=*OUT. Align all the ARM files with that pattern.
See https://ci.appveyor.com/project/conscrypt/conscrypt
Change-Id: Ibee9427a05d806f7f23a6d9817394cfabf2f534a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37324
Reviewed-by: Kenny Root <kroot@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
If the xlate filter script fails, the outer script swallows the error,
unless we check the return value of close.
Change-Id: Ib506bb745a5d27b9d1df9329535bf81ad090f41f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35724
Reviewed-by: Adam Langley <agl@google.com>
This imports ce5eb5e8149d8d03660575f4b8504c993851988a and
1212818eb07add297fe562eba80ac46a9893781e from OpenSSL's 1.1.1 branch.
Change-Id: I121c0771371697191a163a28d972a7b3cee37762
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35164
Reviewed-by: Adam Langley <agl@google.com>
Merge all of these at once:
e2ff2ca0dcda4f37d9675f5d64add4a0ca239af9
ae96383af375d52f30f72554b75272fa226ca795
b9940a649afba6666b9dcea38911203c661981de
8da59555c6d6f11c3f22f8c76f09b057786f657a
f03cdc3a936a4e4f00cd8fcf978ce195db3e717e
3763cbeb6a04c0fd9915ac6606cbf0ac4d4263f5
0a3663a64f00b6337ec80d78c8945f2c77c63dba
Some of these changes had previously been merged from upstream OpenSSL
into *ring* so it's much easier to do a merge of all of these at once
to sort out the real differences.
ARMv8 kindly deprecated most of its IT instructions in Thumb mode.
These files are taken from upstream and are used on both ARMv7 and ARMv8
processors. Accordingly, silence the warnings by marking the file as
targetting ARMv7. In other files, they were accidentally silenced anyway
by way of the existing .arch lines.
This can be reproduced by building with the new NDK and passing
-DCMAKE_ASM_FLAGS=-march=armv8-a. Some of our downstream code ends up
passing that to the assembly.
Note this change does not attempt to arrange for ARMv8-A/T32 to get
code which honors the constraints. It only silences the warnings and
continues to give it the same ARMv7-A/Thumb-2 code that backwards
compatibility dictates it continue to run.
Bug: chromium:575886, b/63131949
Change-Id: I24ce0b695942eaac799347922b243353b43ad7df
Reviewed-on: https://boringssl-review.googlesource.com/24166
Reviewed-by: Adam Langley <agl@google.com>
This change was made by copying over the files as of that commit and
then discarding the parts of the diff which corresponding to our own
changes.
Change-Id: I28c5d711f7a8cec30749b8174687434129af5209
Reviewed-on: https://boringssl-review.googlesource.com/17111
Reviewed-by: Adam Langley <agl@google.com>
As some of ARM processors, more specifically Cortex-Mx series, are
Thumb2-only, we need to support Thumb2-only builds even in assembly.
(Imported from upstream's 11208dcfb9105e8afa37233185decefd45e89e17.)
Change-Id: I7cb48ce6a842cf3cfdf553f6e6e6227d52d525c0
Reviewed-on: https://boringssl-review.googlesource.com/17108
Reviewed-by: Adam Langley <agl@google.com>
This reverts commit 2cd63877b5d663d1f19dca08b36de9746c044f9d. We've
since imported a change to upstream which adds some #defines that should
do the same thing on clang. (Though if gas accepts unified assembly too,
that does seem a better approach. Ah well. Diverging on these files is
expensive.)
This is to reduce the diff and make applying some subsequent changes
easier.
Change-Id: I3f5eae2a71919b291a8de9415b894d8f0c67e3cf
Reviewed-on: https://boringssl-review.googlesource.com/17107
Reviewed-by: Adam Langley <agl@google.com>
The changes to delocate.go are needed because modes/ does things like
return the address of a module function. Both of these need to be
changed from referencing the GOT to using local symbols.
Rather than testing whether |ghash| is |gcm_ghash_avx|, we can just keep
that information in a flag.
The test for |aesni_ctr32_encrypt_blocks| is more problematic, but I
believe that it's superfluous and can be dropped: if you passed in a
stream function that was semantically different from
|aesni_ctr32_encrypt_blocks| you would already have a bug because
|CRYPTO_gcm128_[en|de]crypt_ctr32| will handle a block at the end
themselves, and assume a big-endian, 32-bit counter anyway.
Change-Id: I68a84ebdab6c6006e11e9467e3362d7585461385
Reviewed-on: https://boringssl-review.googlesource.com/15064
Reviewed-by: Adam Langley <agl@google.com>
