boringssl/crypto/crypto.c

174 lines
5.1 KiB
C
Raw Normal View History

/* Copyright (c) 2014, Google Inc.
*
* Permission to use, copy, modify, and/or distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
* SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
* OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */
#include <openssl/crypto.h>
#include <openssl/cpu.h>
#include "internal.h"
#if !defined(OPENSSL_NO_ASM) && !defined(OPENSSL_STATIC_ARMCAP) && \
(defined(OPENSSL_X86) || defined(OPENSSL_X86_64) || \
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
defined(OPENSSL_ARM) || defined(OPENSSL_AARCH64) || \
defined(OPENSSL_PPC64LE))
/* x86, x86_64, the ARMs and ppc64le need to record the result of a
* cpuid/getauxval call for the asm to work correctly, unless compiled without
* asm code. */
#define NEED_CPUID
#else
/* Otherwise, don't emit a static initialiser. */
#if !defined(BORINGSSL_NO_STATIC_INITIALIZER)
#define BORINGSSL_NO_STATIC_INITIALIZER
#endif
#endif /* !OPENSSL_NO_ASM && (OPENSSL_X86 || OPENSSL_X86_64 ||
OPENSSL_ARM || OPENSSL_AARCH64) */
/* The capability variables are defined in this file in order to work around a
* linker bug. When linking with a .a, if no symbols in a .o are referenced
* then the .o is discarded, even if it has constructor functions.
*
* This still means that any binaries that don't include some functionality
* that tests the capability values will still skip the constructor but, so
* far, the init constructor function only sets the capability variables. */
#if defined(OPENSSL_X86) || defined(OPENSSL_X86_64)
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
/* This value must be explicitly initialised to zero in order to work around a
* bug in libtool or the linker on OS X.
*
* If not initialised then it becomes a "common symbol". When put into an
* archive, linking on OS X will fail to resolve common symbols. By
* initialising it to zero, it becomes a "data symbol", which isn't so
* affected. */
uint32_t OPENSSL_ia32cap_P[4] = {0};
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
#elif defined(OPENSSL_PPC64LE)
unsigned long OPENSSL_ppc64le_hwcap2 = 0;
#elif defined(OPENSSL_ARM) || defined(OPENSSL_AARCH64)
#include <openssl/arm_arch.h>
#if defined(OPENSSL_STATIC_ARMCAP)
uint32_t OPENSSL_armcap_P =
#if defined(OPENSSL_STATIC_ARMCAP_NEON) || defined(__ARM_NEON__)
ARMV7_NEON |
#endif
#if defined(OPENSSL_STATIC_ARMCAP_AES) || defined(__ARM_FEATURE_CRYPTO)
ARMV8_AES |
#endif
#if defined(OPENSSL_STATIC_ARMCAP_SHA1) || defined(__ARM_FEATURE_CRYPTO)
ARMV8_SHA1 |
#endif
#if defined(OPENSSL_STATIC_ARMCAP_SHA256) || defined(__ARM_FEATURE_CRYPTO)
ARMV8_SHA256 |
#endif
#if defined(OPENSSL_STATIC_ARMCAP_PMULL) || defined(__ARM_FEATURE_CRYPTO)
ARMV8_PMULL |
#endif
0;
#else
uint32_t OPENSSL_armcap_P = 0;
#endif
#endif
#if defined(BORINGSSL_FIPS)
/* In FIPS mode, the power-on self-test function calls |CRYPTO_library_init|
* because we have to ensure that CPUID detection occurs first. */
#define BORINGSSL_NO_STATIC_INITIALIZER
#endif
#if defined(OPENSSL_WINDOWS) && !defined(BORINGSSL_NO_STATIC_INITIALIZER)
#define OPENSSL_CDECL __cdecl
#else
#define OPENSSL_CDECL
#endif
#if defined(BORINGSSL_NO_STATIC_INITIALIZER)
static CRYPTO_once_t once = CRYPTO_ONCE_INIT;
#elif defined(OPENSSL_WINDOWS)
#pragma section(".CRT$XCU", read)
static void __cdecl do_library_init(void);
__declspec(allocate(".CRT$XCU")) void(*library_init_constructor)(void) =
do_library_init;
#else
static void do_library_init(void) __attribute__ ((constructor));
#endif
/* do_library_init is the actual initialization function. If
* BORINGSSL_NO_STATIC_INITIALIZER isn't defined, this is set as a static
* initializer. Otherwise, it is called by CRYPTO_library_init. */
static void OPENSSL_CDECL do_library_init(void) {
/* WARNING: this function may only configure the capability variables. See the
* note above about the linker bug. */
#if defined(NEED_CPUID)
OPENSSL_cpuid_setup();
#endif
}
void CRYPTO_library_init(void) {
/* TODO(davidben): It would be tidier if this build knob could be replaced
* with an internal lazy-init mechanism that would handle things correctly
* in-library. https://crbug.com/542879 */
#if defined(BORINGSSL_NO_STATIC_INITIALIZER)
CRYPTO_once(&once, do_library_init);
#endif
}
int CRYPTO_is_confidential_build(void) {
#if defined(BORINGSSL_CONFIDENTIAL)
return 1;
#else
return 0;
#endif
}
int CRYPTO_has_asm(void) {
#if defined(OPENSSL_NO_ASM)
return 0;
#else
return 1;
#endif
}
const char *SSLeay_version(int unused) {
return "BoringSSL";
}
unsigned long SSLeay(void) {
return OPENSSL_VERSION_NUMBER;
}
int CRYPTO_malloc_init(void) {
return 1;
}
void ENGINE_load_builtin_engines(void) {}
int ENGINE_register_all_complete(void) {
return 1;
}
void OPENSSL_load_builtin_modules(void) {}