kris/boringssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
f64a6eeaf0
boringssl/include/openssl/cpu.h

193 lines
6.8 KiB
C
Raw Normal View History

Move public headers to include/openssl/ Previously, public headers lived next to the respective code and there were symlinks from include/openssl to them. This doesn't work on Windows. This change moves the headers to live in include/openssl. In cases where some symlinks pointed to the same header, I've added a file that just includes the intended target. These cases are all for backwards-compat. Change-Id: I6e285b74caf621c644b5168a4877db226b07fd92 Reviewed-on: https://boringssl-review.googlesource.com/1180 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2014-07-14 23:28:14 +01:00
/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)
* All rights reserved.
*
* This package is an SSL implementation written
* by Eric Young (eay@cryptsoft.com).
* The implementation was written so as to conform with Netscapes SSL.
*
* This library is free for commercial and non-commercial use as long as
* the following conditions are aheared to. The following conditions
* apply to all code found in this distribution, be it the RC4, RSA,
* lhash, DES, etc., code; not just the SSL code. The SSL documentation
* included with this distribution is covered by the same copyright terms
* except that the holder is Tim Hudson (tjh@cryptsoft.com).
*
* Copyright remains Eric Young's, and as such any Copyright notices in
* the code are not to be removed.
* If this package is used in a product, Eric Young should be given attribution
* as the author of the parts of the library used.
* This can be in the form of a textual message at program startup or
* in documentation (online or textual) provided with the package.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* "This product includes cryptographic software written by
* Eric Young (eay@cryptsoft.com)"
* The word 'cryptographic' can be left out if the rouines from the library
* being used are not cryptographic related :-).
* 4. If you include any Windows specific code (or a derivative thereof) from
* the apps directory (application code) you must include an acknowledgement:
* "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
*
* THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* The licence and distribution terms for any publically available version or
* derivative of this code cannot be changed. i.e. this code cannot simply be
* copied and put under another distribution licence
* [including the GNU Public Licence.]
*
* This product includes cryptographic software written by Eric Young
* (eay@cryptsoft.com). This product includes software written by Tim
* Hudson (tjh@cryptsoft.com). */
#ifndef OPENSSL_HEADER_CPU_H
#define OPENSSL_HEADER_CPU_H
#include <openssl/base.h>
#if defined(__cplusplus)
extern "C" {
#endif
Various documentation fixes. Add some missing headers and ensure each header has a short description. doc.go gets confused at declarations that break before the first (, so avoid doing that. Also skip a/an/deprecated: in markupFirstWord and process pipe words in the table of contents. Change-Id: Ia08ec5ae8e496dd617e377e154eeea74f4abf435 Reviewed-on: https://boringssl-review.googlesource.com/2839 Reviewed-by: Adam Langley <agl@google.com>
2014-12-26 05:54:52 +00:00
/* Runtime CPU feature support */
Move public headers to include/openssl/ Previously, public headers lived next to the respective code and there were symlinks from include/openssl to them. This doesn't work on Windows. This change moves the headers to live in include/openssl. In cases where some symlinks pointed to the same header, I've added a file that just includes the intended target. These cases are all for backwards-compat. Change-Id: I6e285b74caf621c644b5168a4877db226b07fd92 Reviewed-on: https://boringssl-review.googlesource.com/1180 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2014-07-14 23:28:14 +01:00
#if defined(OPENSSL_X86) || defined(OPENSSL_X86_64)
/* OPENSSL_ia32cap_P contains the Intel CPUID bits when running on an x86 or
* x86-64 system.
*
* Index 0:
* EDX for CPUID where EAX = 1
Extra documentation. Some other reserved bits are repurposed. Also explicitly mention that bit 20 is zero (formerly RC4_CHAR), so it's not accidentally repurposed later. Change-Id: Idc4b32efe089ae7b7295472c4488f75258b7f962 Reviewed-on: https://boringssl-review.googlesource.com/5432 Reviewed-by: Adam Langley <agl@google.com>
2015-07-11 14:46:55 +01:00
* Bit 20 is always zero
* Bit 28 is adjusted to reflect whether the data cache is shared between
* multiple logical cores
Move public headers to include/openssl/ Previously, public headers lived next to the respective code and there were symlinks from include/openssl to them. This doesn't work on Windows. This change moves the headers to live in include/openssl. In cases where some symlinks pointed to the same header, I've added a file that just includes the intended target. These cases are all for backwards-compat. Change-Id: I6e285b74caf621c644b5168a4877db226b07fd92 Reviewed-on: https://boringssl-review.googlesource.com/1180 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2014-07-14 23:28:14 +01:00
* Bit 30 is used to indicate an Intel CPU
* Index 1:
* ECX for CPUID where EAX = 1
Extra documentation. Some other reserved bits are repurposed. Also explicitly mention that bit 20 is zero (formerly RC4_CHAR), so it's not accidentally repurposed later. Change-Id: Idc4b32efe089ae7b7295472c4488f75258b7f962 Reviewed-on: https://boringssl-review.googlesource.com/5432 Reviewed-by: Adam Langley <agl@google.com>
2015-07-11 14:46:55 +01:00
* Bit 11 is used to indicate AMD XOP support, not SDBG
Move public headers to include/openssl/ Previously, public headers lived next to the respective code and there were symlinks from include/openssl to them. This doesn't work on Windows. This change moves the headers to live in include/openssl. In cases where some symlinks pointed to the same header, I've added a file that just includes the intended target. These cases are all for backwards-compat. Change-Id: I6e285b74caf621c644b5168a4877db226b07fd92 Reviewed-on: https://boringssl-review.googlesource.com/1180 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2014-07-14 23:28:14 +01:00
* Index 2:
Prefer AES-GCM when hardware support is available. BUG=396787 Change-Id: I72ddb0ec3c71dbc70054403163930cbbde4b6009 Reviewed-on: https://boringssl-review.googlesource.com/1581 Reviewed-by: Adam Langley <agl@google.com>
2014-08-20 19:19:54 +01:00
* EBX for CPUID where EAX = 7
Extra documentation. Some other reserved bits are repurposed. Also explicitly mention that bit 20 is zero (formerly RC4_CHAR), so it's not accidentally repurposed later. Change-Id: Idc4b32efe089ae7b7295472c4488f75258b7f962 Reviewed-on: https://boringssl-review.googlesource.com/5432 Reviewed-by: Adam Langley <agl@google.com>
2015-07-11 14:46:55 +01:00
* Index 3 is set to zero.
Prefer AES-GCM when hardware support is available. BUG=396787 Change-Id: I72ddb0ec3c71dbc70054403163930cbbde4b6009 Reviewed-on: https://boringssl-review.googlesource.com/1581 Reviewed-by: Adam Langley <agl@google.com>
2014-08-20 19:19:54 +01:00
*
* Note: the CPUID bits are pre-adjusted for the OSXSAVE bit and the YMM and XMM
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
2015-07-11 14:47:14 +01:00
* bits in XCR0, so it is not necessary to check those. */
Move public headers to include/openssl/ Previously, public headers lived next to the respective code and there were symlinks from include/openssl to them. This doesn't work on Windows. This change moves the headers to live in include/openssl. In cases where some symlinks pointed to the same header, I've added a file that just includes the intended target. These cases are all for backwards-compat. Change-Id: I6e285b74caf621c644b5168a4877db226b07fd92 Reviewed-on: https://boringssl-review.googlesource.com/1180 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2014-07-14 23:28:14 +01:00
extern uint32_t OPENSSL_ia32cap_P[4];
Add an OPENSSL_ia32cap_get() function for C code. OPENSSL_ia32cap_addr avoids any relocations within the module, at the cost of a runtime TEXTREL, which causes problems in some cases. (Notably, if someone links us into a binary which uses the GCC "ifunc" attribute, the loader crashes.) Fix C references of OPENSSL_ia32cap_addr with a function. This is analogous to the BSS getters. A follow-up commit will fix perlasm with a different scheme which avoids calling into a function (clobbering registers and complicating unwind directives.) Change-Id: I09d6cda4cec35b693e16b5387611167da8c7a6de Reviewed-on: https://boringssl-review.googlesource.com/15525 Reviewed-by: Adam Langley <agl@google.com>
2017-04-25 20:37:53 +01:00
#if defined(BORINGSSL_FIPS)
const uint32_t *OPENSSL_ia32cap_get(void);
#else
static inline const uint32_t *OPENSSL_ia32cap_get(void) {
return OPENSSL_ia32cap_P;
}
#endif
Move public headers to include/openssl/ Previously, public headers lived next to the respective code and there were symlinks from include/openssl to them. This doesn't work on Windows. This change moves the headers to live in include/openssl. In cases where some symlinks pointed to the same header, I've added a file that just includes the intended target. These cases are all for backwards-compat. Change-Id: I6e285b74caf621c644b5168a4877db226b07fd92 Reviewed-on: https://boringssl-review.googlesource.com/1180 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2014-07-14 23:28:14 +01:00
#endif
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-09 23:44:37 +00:00
#if defined(OPENSSL_ARM) || defined(OPENSSL_AARCH64)
Allow ARM capabilities to be set at compile time. Some ARM environments don't support |getauxval| or signals and need to configure the capabilities of the chip at compile time. This change adds defines that allow them to do so. Change-Id: I4e6987f69dd13444029bc7ac7ed4dbf8fb1faa76 Reviewed-on: https://boringssl-review.googlesource.com/6280 Reviewed-by: Adam Langley <agl@google.com>
2015-10-16 23:46:46 +01:00
iOS builds use the static ARM CPU configuration. The other codepath is Linux-specific. This should get tidied up a bit but, in the meantime, fix the Chromium iOS (NO_ASM) build. Even when the assembly gets working, it seems iOS prefers you make fat binaries rather than detect features at runtime, so this is what we want anyway. BUG=548539 Change-Id: If19b2e380a96918b07bacc300a3a27b885697b99 Reviewed-on: https://boringssl-review.googlesource.com/6380 Reviewed-by: Adam Langley <agl@google.com>
2015-10-28 16:40:12 +00:00
#if defined(OPENSSL_APPLE)
/* iOS builds use the static ARM configuration. */
#define OPENSSL_STATIC_ARMCAP
#endif
Allow ARM capabilities to be set at compile time. Some ARM environments don't support |getauxval| or signals and need to configure the capabilities of the chip at compile time. This change adds defines that allow them to do so. Change-Id: I4e6987f69dd13444029bc7ac7ed4dbf8fb1faa76 Reviewed-on: https://boringssl-review.googlesource.com/6280 Reviewed-by: Adam Langley <agl@google.com>
2015-10-16 23:46:46 +01:00
#if !defined(OPENSSL_STATIC_ARMCAP)
Allow |CRYPTO_is_NEON_capable| to be known at compile time, if possible. If -mfpu=neon is passed then we don't need to worry about checking for NEON support at run time. This change allows |CRYPTO_is_NEON_capable| to statically return 1 in this case. This then allows the compiler to discard generic code in several cases. Change-Id: I3b229740ea3d5cb0a304f365c400a0996d0c66ef Reviewed-on: https://boringssl-review.googlesource.com/6523 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2015-11-17 23:25:00 +00:00
/* CRYPTO_is_NEON_capable_at_runtime returns true if the current CPU has a NEON
* unit. Note that |OPENSSL_armcap_P| also exists and contains the same
* information in a form that's easier for assembly to use. */
OPENSSL_EXPORT char CRYPTO_is_NEON_capable_at_runtime(void);
/* CRYPTO_is_NEON_capable returns true if the current CPU has a NEON unit. If
* this is known statically then it returns one immediately. */
static inline int CRYPTO_is_NEON_capable(void) {
Make CRYPTO_is_NEON_capable aware of the buggy CPU. If we're to allow the buggy CPU workaround to fire when __ARM_NEON__ is set, CRYPTO_is_NEON_capable also needs to be aware of it. Also add an API to export this value out of BoringSSL, so we can get some metrics on how prevalent this chip is. BUG=chromium:606629 Change-Id: I97d65a47a6130689098b32ce45a8c57c468aa405 Reviewed-on: https://boringssl-review.googlesource.com/7796 Reviewed-by: Adam Langley <agl@google.com>
2016-04-28 17:17:55 +01:00
/* Only statically skip the runtime lookup on aarch64. On arm, one CPU is
* known to have a broken NEON unit which is known to fail with on some
* hand-written NEON assembly. For now, continue to apply the workaround even
* when the compiler is instructed to freely emit NEON code. See
* https://crbug.com/341598 and https://crbug.com/606629. */
#if defined(__ARM_NEON__) && !defined(OPENSSL_ARM)
Allow |CRYPTO_is_NEON_capable| to be known at compile time, if possible. If -mfpu=neon is passed then we don't need to worry about checking for NEON support at run time. This change allows |CRYPTO_is_NEON_capable| to statically return 1 in this case. This then allows the compiler to discard generic code in several cases. Change-Id: I3b229740ea3d5cb0a304f365c400a0996d0c66ef Reviewed-on: https://boringssl-review.googlesource.com/6523 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2015-11-17 23:25:00 +00:00
return 1;
#else
return CRYPTO_is_NEON_capable_at_runtime();
#endif
}
Move public headers to include/openssl/ Previously, public headers lived next to the respective code and there were symlinks from include/openssl to them. This doesn't work on Windows. This change moves the headers to live in include/openssl. In cases where some symlinks pointed to the same header, I've added a file that just includes the intended target. These cases are all for backwards-compat. Change-Id: I6e285b74caf621c644b5168a4877db226b07fd92 Reviewed-on: https://boringssl-review.googlesource.com/1180 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2014-07-14 23:28:14 +01:00
Make CRYPTO_is_NEON_capable aware of the buggy CPU. If we're to allow the buggy CPU workaround to fire when __ARM_NEON__ is set, CRYPTO_is_NEON_capable also needs to be aware of it. Also add an API to export this value out of BoringSSL, so we can get some metrics on how prevalent this chip is. BUG=chromium:606629 Change-Id: I97d65a47a6130689098b32ce45a8c57c468aa405 Reviewed-on: https://boringssl-review.googlesource.com/7796 Reviewed-by: Adam Langley <agl@google.com>
2016-04-28 17:17:55 +01:00
#if defined(OPENSSL_ARM)
/* CRYPTO_has_broken_NEON returns one if the current CPU is known to have a
* broken NEON unit. See https://crbug.com/341598. */
OPENSSL_EXPORT int CRYPTO_has_broken_NEON(void);
#endif
Allow ARM capabilities to be set at compile time. Some ARM environments don't support |getauxval| or signals and need to configure the capabilities of the chip at compile time. This change adds defines that allow them to do so. Change-Id: I4e6987f69dd13444029bc7ac7ed4dbf8fb1faa76 Reviewed-on: https://boringssl-review.googlesource.com/6280 Reviewed-by: Adam Langley <agl@google.com>
2015-10-16 23:46:46 +01:00
/* CRYPTO_is_ARMv8_AES_capable returns true if the current CPU supports the
* ARMv8 AES instruction. */
int CRYPTO_is_ARMv8_AES_capable(void);
/* CRYPTO_is_ARMv8_PMULL_capable returns true if the current CPU supports the
* ARMv8 PMULL instruction. */
int CRYPTO_is_ARMv8_PMULL_capable(void);
#else
static inline int CRYPTO_is_NEON_capable(void) {
#if defined(OPENSSL_STATIC_ARMCAP_NEON) || defined(__ARM_NEON__)
return 1;
#else
return 0;
#endif
}
static inline int CRYPTO_is_ARMv8_AES_capable(void) {
#if defined(OPENSSL_STATIC_ARMCAP_AES)
return 1;
#else
return 0;
#endif
}
static inline int CRYPTO_is_ARMv8_PMULL_capable(void) {
#if defined(OPENSSL_STATIC_ARMCAP_PMULL)
return 1;
#else
return 0;
#endif
}
#endif /* OPENSSL_STATIC_ARMCAP */
Make CRYPTO_is_NEON_capable aware of the buggy CPU. If we're to allow the buggy CPU workaround to fire when __ARM_NEON__ is set, CRYPTO_is_NEON_capable also needs to be aware of it. Also add an API to export this value out of BoringSSL, so we can get some metrics on how prevalent this chip is. BUG=chromium:606629 Change-Id: I97d65a47a6130689098b32ce45a8c57c468aa405 Reviewed-on: https://boringssl-review.googlesource.com/7796 Reviewed-by: Adam Langley <agl@google.com>
2016-04-28 17:17:55 +01:00
#endif /* OPENSSL_ARM || OPENSSL_AARCH64 */
Move public headers to include/openssl/ Previously, public headers lived next to the respective code and there were symlinks from include/openssl to them. This doesn't work on Windows. This change moves the headers to live in include/openssl. In cases where some symlinks pointed to the same header, I've added a file that just includes the intended target. These cases are all for backwards-compat. Change-Id: I6e285b74caf621c644b5168a4877db226b07fd92 Reviewed-on: https://boringssl-review.googlesource.com/1180 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2014-07-14 23:28:14 +01:00
Add PPC64LE assembly for AES-GCM. This change adds AES and GHASH assembly from upstream, with the aim of speeding up AES-GCM. The PPC64LE assembly matches the interface of the ARMv8 assembly so I've changed the prefix of both sets of asm functions to be the same ("aes_hw_"). Otherwise, the new assmebly files and Perlasm match exactly those from upstream's c536b6be1a (from their master branch). Before: Did 1879000 AES-128-GCM (16 bytes) seal operations in 1000428us (1878196.1 ops/sec): 30.1 MB/s Did 61000 AES-128-GCM (1350 bytes) seal operations in 1006660us (60596.4 ops/sec): 81.8 MB/s Did 11000 AES-128-GCM (8192 bytes) seal operations in 1072649us (10255.0 ops/sec): 84.0 MB/s Did 1665000 AES-256-GCM (16 bytes) seal operations in 1000591us (1664016.6 ops/sec): 26.6 MB/s Did 52000 AES-256-GCM (1350 bytes) seal operations in 1006971us (51640.0 ops/sec): 69.7 MB/s Did 8840 AES-256-GCM (8192 bytes) seal operations in 1013294us (8724.0 ops/sec): 71.5 MB/s After: Did 4994000 AES-128-GCM (16 bytes) seal operations in 1000017us (4993915.1 ops/sec): 79.9 MB/s Did 1389000 AES-128-GCM (1350 bytes) seal operations in 1000073us (1388898.6 ops/sec): 1875.0 MB/s Did 319000 AES-128-GCM (8192 bytes) seal operations in 1000101us (318967.8 ops/sec): 2613.0 MB/s Did 4668000 AES-256-GCM (16 bytes) seal operations in 1000149us (4667304.6 ops/sec): 74.7 MB/s Did 1202000 AES-256-GCM (1350 bytes) seal operations in 1000646us (1201224.0 ops/sec): 1621.7 MB/s Did 269000 AES-256-GCM (8192 bytes) seal operations in 1002804us (268247.8 ops/sec): 2197.5 MB/s Change-Id: Id848562bd4e1aa79a4683012501dfa5e6c08cfcc Reviewed-on: https://boringssl-review.googlesource.com/11262 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2016-09-23 20:47:24 +01:00
#if defined(OPENSSL_PPC64LE)
/* CRYPTO_is_PPC64LE_vcrypto_capable returns true iff the current CPU supports
* the Vector.AES category of instructions. */
int CRYPTO_is_PPC64LE_vcrypto_capable(void);
Make the POWER hardware capability value a global in crypto.c. (Thanks to Sam Panzer for the patch.) At least some linkers will drop constructor functions if no symbols from that translation unit are used elsewhere in the program. On POWER, since the cached capability value isn't a global in crypto.o (like other platforms), the constructor function is getting discarded. The C++11 spec says (3.6.2, paragraph 4): It is implementation-defined whether the dynamic initialization of a non-local variable with static storage duration is done before the first statement of main. If the initialization is deferred to some point in time after the first statement of main, it shall occur before the first odr-use (3.2) of any function or variable defined in the same translation unit as the variable to be initialized. Compilers appear to interpret that to mean they are allowed to drop (i.e. indefinitely defer) constructors that occur in translation units that are never used, so they can avoid initializing some part of a library if it's dropped on the floor. This change makes the hardware capability value for POWER a global in crypto.c, which should prevent the constructor function from being ignored. Change-Id: I43ebe492d0ac1491f6f6c2097971a277f923dd3e Reviewed-on: https://boringssl-review.googlesource.com/14664 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-04-04 19:08:28 +01:00
extern unsigned long OPENSSL_ppc64le_hwcap2;
Add PPC64LE assembly for AES-GCM. This change adds AES and GHASH assembly from upstream, with the aim of speeding up AES-GCM. The PPC64LE assembly matches the interface of the ARMv8 assembly so I've changed the prefix of both sets of asm functions to be the same ("aes_hw_"). Otherwise, the new assmebly files and Perlasm match exactly those from upstream's c536b6be1a (from their master branch). Before: Did 1879000 AES-128-GCM (16 bytes) seal operations in 1000428us (1878196.1 ops/sec): 30.1 MB/s Did 61000 AES-128-GCM (1350 bytes) seal operations in 1006660us (60596.4 ops/sec): 81.8 MB/s Did 11000 AES-128-GCM (8192 bytes) seal operations in 1072649us (10255.0 ops/sec): 84.0 MB/s Did 1665000 AES-256-GCM (16 bytes) seal operations in 1000591us (1664016.6 ops/sec): 26.6 MB/s Did 52000 AES-256-GCM (1350 bytes) seal operations in 1006971us (51640.0 ops/sec): 69.7 MB/s Did 8840 AES-256-GCM (8192 bytes) seal operations in 1013294us (8724.0 ops/sec): 71.5 MB/s After: Did 4994000 AES-128-GCM (16 bytes) seal operations in 1000017us (4993915.1 ops/sec): 79.9 MB/s Did 1389000 AES-128-GCM (1350 bytes) seal operations in 1000073us (1388898.6 ops/sec): 1875.0 MB/s Did 319000 AES-128-GCM (8192 bytes) seal operations in 1000101us (318967.8 ops/sec): 2613.0 MB/s Did 4668000 AES-256-GCM (16 bytes) seal operations in 1000149us (4667304.6 ops/sec): 74.7 MB/s Did 1202000 AES-256-GCM (1350 bytes) seal operations in 1000646us (1201224.0 ops/sec): 1621.7 MB/s Did 269000 AES-256-GCM (8192 bytes) seal operations in 1002804us (268247.8 ops/sec): 2197.5 MB/s Change-Id: Id848562bd4e1aa79a4683012501dfa5e6c08cfcc Reviewed-on: https://boringssl-review.googlesource.com/11262 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2016-09-23 20:47:24 +01:00
#endif /* OPENSSL_PPC64LE */
Move public headers to include/openssl/ Previously, public headers lived next to the respective code and there were symlinks from include/openssl to them. This doesn't work on Windows. This change moves the headers to live in include/openssl. In cases where some symlinks pointed to the same header, I've added a file that just includes the intended target. These cases are all for backwards-compat. Change-Id: I6e285b74caf621c644b5168a4877db226b07fd92 Reviewed-on: https://boringssl-review.googlesource.com/1180 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2014-07-14 23:28:14 +01:00
#if defined(__cplusplus)
} /* extern C */
#endif
#endif /* OPENSSL_HEADER_CPU_H */
Reference in New Issue Copy Permalink