Commit Graph

3 Commits

Author SHA1 Message Date
Adam Langley
3e6526575a aarch64 support.
This is an initial cut at aarch64 support. I have only qemu to test it
however—hopefully hardware will be coming soon.

This also affects 32-bit ARM in that aarch64 chips can run 32-bit code
and we would like to be able to take advantage of the crypto operations
even in 32-bit mode. AES and GHASH should Just Work in this case: the
-armx.pl files can be built for either 32- or 64-bit mode based on the
flavour argument given to the Perl script.

SHA-1 and SHA-256 don't work like this however because they've never
support for multiple implementations, thus BoringSSL built for 32-bit
won't use the SHA instructions on an aarch64 chip.

No dedicated ChaCha20 or Poly1305 support yet.

Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c
Reviewed-on: https://boringssl-review.googlesource.com/2801
Reviewed-by: Adam Langley <agl@google.com>
2015-01-14 23:38:11 +00:00
Adam Langley
588d2528d1 Don't try to setup CPUID if NO_ASM.
Change-Id: Idec1cda87b0a58e9350d0e10c3251a2c47ac1929
Reviewed-on: https://boringssl-review.googlesource.com/1790
Reviewed-by: Adam Langley <agl@google.com>
2014-09-20 00:09:57 +00:00
David Benjamin
a70c75cfc0 Add a CRYPTO_library_init and static-initializer-less build option.
Chromium does not like static initializers, and the CPU logic uses one to
initialize CPU bits. However, the crypto library lacks an explicit
initialization function, which could complicate (no compile-time errors)
porting existing code which uses crypto/, but not ssl/.

Add an explicit CRYPTO_library_init function, but make it a no-op by default.
It only does anything (and is required) if building with
BORINGSSL_NO_STATIC_INITIALIZER.

Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39
Reviewed-on: https://boringssl-review.googlesource.com/1770
Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:10:53 +00:00