boringssl/crypto/crypto.c

217 lines
6.8 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_MSAN) && !defined(OPENSSL_NO_ASM)
// MSan works by instrumenting memory accesses in the compiler. Accesses from
// uninstrumented code, such as assembly, are invisible to it. MSan will
// incorrectly report reads from assembly-initialized memory as uninitialized.
// If building BoringSSL with MSan, exclude assembly files from the build and
// define OPENSSL_NO_ASM.
//
// This is checked here rather than in a header because the consumer might not
// define OPENSSL_NO_ASM. It is only necessary for BoringSSL source files to be
// built with it.
#error "BoringSSL must be built with assembly disabled to use MSan."
#endif
#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) */
// Our assembly does not use the GOT to reference symbols, which means
// references to visible symbols will often require a TEXTREL. This is
// undesirable, so all assembly-referenced symbols should be hidden. CPU
// capabilities are the only such symbols defined in C. Explicitly hide them,
// rather than rely on being built with -fvisibility=hidden.
#if defined(OPENSSL_WINDOWS)
#define HIDDEN
#else
#define HIDDEN __attribute__((visibility("hidden")))
#endif
// 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.
HIDDEN 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)
HIDDEN unsigned long OPENSSL_ppc64le_hwcap2 = 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_ARM) || defined(OPENSSL_AARCH64)
#include <openssl/arm_arch.h>
#if defined(OPENSSL_STATIC_ARMCAP)
HIDDEN 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
HIDDEN 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(_MSC_VER)
#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 which) { return OpenSSL_version(which); }
const char *OpenSSL_version(int which) {
switch (which) {
case OPENSSL_VERSION:
return "BoringSSL";
case OPENSSL_CFLAGS:
return "compiler: n/a";
case OPENSSL_BUILT_ON:
return "built on: n/a";
case OPENSSL_PLATFORM:
return "platform: n/a";
case OPENSSL_DIR:
return "OPENSSLDIR: n/a";
default:
return "not available";
}
}
Switch OPENSSL_VERSION_NUMBER to 1.1.0. Although we are derived from 1.0.2, we mimic 1.1.0 in some ways around our FOO_up_ref functions and opaque libssl types. This causes some difficulties when porting third-party code as any OPENSSL_VERSION_NUMBER checks for 1.1.0 APIs we have will be wrong. Moreover, adding accessors without changing OPENSSL_VERSION_NUMBER can break external projects. It is common to implement a compatibility version of an accessor under #ifdef as a static function. This then conflicts with our headers if we, unlike OpenSSL 1.0.2, have this function. This change switches OPENSSL_VERSION_NUMBER to 1.1.0 and atomically adds enough accessors for software with 1.1.0 support already. The hope is this will unblock hiding SSL_CTX and SSL_SESSION, which will be especially useful with C++-ficiation. The cost is we will hit some growing pains as more 1.1.0 consumers enter the ecosystem and we converge on the right set of APIs to import from upstream. It does not remove any 1.0.2 APIs, so we will not require that all projects support 1.1.0. The exception is APIs which changed in 1.1.0 but did not change the function signature. Those are breaking changes. Specifically: - SSL_CTX_sess_set_get_cb is now const-correct. - X509_get0_signature is now const-correct. For C++ consumers only, this change temporarily includes an overload hack for SSL_CTX_sess_set_get_cb that keeps the old callback working. This is a workaround for Node not yet supporting OpenSSL 1.1.0. The version number is set at (the as yet unreleased) 1.1.0g to denote that this change includes https://github.com/openssl/openssl/pull/4384. Bug: 91 Change-Id: I5eeb27448a6db4c25c244afac37f9604d9608a76 Reviewed-on: https://boringssl-review.googlesource.com/10340 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-08-12 19:48:19 +01:00
unsigned long SSLeay(void) { return OPENSSL_VERSION_NUMBER; }
unsigned long OpenSSL_version_num(void) { return OPENSSL_VERSION_NUMBER; }
Switch OPENSSL_VERSION_NUMBER to 1.1.0. Although we are derived from 1.0.2, we mimic 1.1.0 in some ways around our FOO_up_ref functions and opaque libssl types. This causes some difficulties when porting third-party code as any OPENSSL_VERSION_NUMBER checks for 1.1.0 APIs we have will be wrong. Moreover, adding accessors without changing OPENSSL_VERSION_NUMBER can break external projects. It is common to implement a compatibility version of an accessor under #ifdef as a static function. This then conflicts with our headers if we, unlike OpenSSL 1.0.2, have this function. This change switches OPENSSL_VERSION_NUMBER to 1.1.0 and atomically adds enough accessors for software with 1.1.0 support already. The hope is this will unblock hiding SSL_CTX and SSL_SESSION, which will be especially useful with C++-ficiation. The cost is we will hit some growing pains as more 1.1.0 consumers enter the ecosystem and we converge on the right set of APIs to import from upstream. It does not remove any 1.0.2 APIs, so we will not require that all projects support 1.1.0. The exception is APIs which changed in 1.1.0 but did not change the function signature. Those are breaking changes. Specifically: - SSL_CTX_sess_set_get_cb is now const-correct. - X509_get0_signature is now const-correct. For C++ consumers only, this change temporarily includes an overload hack for SSL_CTX_sess_set_get_cb that keeps the old callback working. This is a workaround for Node not yet supporting OpenSSL 1.1.0. The version number is set at (the as yet unreleased) 1.1.0g to denote that this change includes https://github.com/openssl/openssl/pull/4384. Bug: 91 Change-Id: I5eeb27448a6db4c25c244afac37f9604d9608a76 Reviewed-on: https://boringssl-review.googlesource.com/10340 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-08-12 19:48:19 +01:00
int CRYPTO_malloc_init(void) { return 1; }
int OPENSSL_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) {}
Switch OPENSSL_VERSION_NUMBER to 1.1.0. Although we are derived from 1.0.2, we mimic 1.1.0 in some ways around our FOO_up_ref functions and opaque libssl types. This causes some difficulties when porting third-party code as any OPENSSL_VERSION_NUMBER checks for 1.1.0 APIs we have will be wrong. Moreover, adding accessors without changing OPENSSL_VERSION_NUMBER can break external projects. It is common to implement a compatibility version of an accessor under #ifdef as a static function. This then conflicts with our headers if we, unlike OpenSSL 1.0.2, have this function. This change switches OPENSSL_VERSION_NUMBER to 1.1.0 and atomically adds enough accessors for software with 1.1.0 support already. The hope is this will unblock hiding SSL_CTX and SSL_SESSION, which will be especially useful with C++-ficiation. The cost is we will hit some growing pains as more 1.1.0 consumers enter the ecosystem and we converge on the right set of APIs to import from upstream. It does not remove any 1.0.2 APIs, so we will not require that all projects support 1.1.0. The exception is APIs which changed in 1.1.0 but did not change the function signature. Those are breaking changes. Specifically: - SSL_CTX_sess_set_get_cb is now const-correct. - X509_get0_signature is now const-correct. For C++ consumers only, this change temporarily includes an overload hack for SSL_CTX_sess_set_get_cb that keeps the old callback working. This is a workaround for Node not yet supporting OpenSSL 1.1.0. The version number is set at (the as yet unreleased) 1.1.0g to denote that this change includes https://github.com/openssl/openssl/pull/4384. Bug: 91 Change-Id: I5eeb27448a6db4c25c244afac37f9604d9608a76 Reviewed-on: https://boringssl-review.googlesource.com/10340 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-08-12 19:48:19 +01:00
int OPENSSL_init_crypto(uint64_t opts, const OPENSSL_INIT_SETTINGS *settings) {
CRYPTO_library_init();
return 1;
}