|
|
|
/* 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>
|
|
|
|
|
Introduce ossl_ssize_t and use it in ASN1_STRING_set.
We have a number of APIs that cannot migrate to size_t because OpenSSL
used negative numbers as some special indicator. This makes it hard to
become size_t-clean.
However, in reality, the largest buffer size is SSIZE_MAX, or, more
accurately PTRDIFF_MAX. But every platform I've ever seen make ptrdiff_t
and size_t the same size. malloc is just obligated to fail allocations
that don't fit in ssize_t. ssize_t itself is not portable (Windows
doesn't have it), but we can define ossl_ssize_t to be ptrdiff_t.
OpenSSL also has an ossl_ssize_t (though they don't use it much), so
we're also improving compatibility.
Start this out with ASN1_STRING_set. It still internally refuses to
construct a string bigger than INT_MAX; the struct can't hold this and
even if we fix the struct, no other code, inside or outside the library,
can tolerate it. But now code which passes in a size_t (including our
own) can do so without overflow.
Bug: 428, 516
Change-Id: I17aa6971733f34dfda7d971882d0f062e92340e9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54953
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
2 years ago
|
|
|
#include <assert.h>
|
|
|
|
|
|
|
|
#include "fipsmodule/rand/fork_detect.h"
|
|
|
|
#include "fipsmodule/rand/internal.h"
|
|
|
|
#include "internal.h"
|
|
|
|
|
|
|
|
|
Introduce ossl_ssize_t and use it in ASN1_STRING_set.
We have a number of APIs that cannot migrate to size_t because OpenSSL
used negative numbers as some special indicator. This makes it hard to
become size_t-clean.
However, in reality, the largest buffer size is SSIZE_MAX, or, more
accurately PTRDIFF_MAX. But every platform I've ever seen make ptrdiff_t
and size_t the same size. malloc is just obligated to fail allocations
that don't fit in ssize_t. ssize_t itself is not portable (Windows
doesn't have it), but we can define ossl_ssize_t to be ptrdiff_t.
OpenSSL also has an ossl_ssize_t (though they don't use it much), so
we're also improving compatibility.
Start this out with ASN1_STRING_set. It still internally refuses to
construct a string bigger than INT_MAX; the struct can't hold this and
even if we fix the struct, no other code, inside or outside the library,
can tolerate it. But now code which passes in a size_t (including our
own) can do so without overflow.
Bug: 428, 516
Change-Id: I17aa6971733f34dfda7d971882d0f062e92340e9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54953
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
2 years ago
|
|
|
static_assert(sizeof(ossl_ssize_t) == sizeof(size_t),
|
|
|
|
"ossl_ssize_t should be the same size as size_t");
|
|
|
|
|
|
|
|
#if !defined(OPENSSL_NO_ASM) && !defined(OPENSSL_STATIC_ARMCAP) && \
|
|
|
|
(defined(OPENSSL_X86) || defined(OPENSSL_X86_64) || \
|
|
|
|
defined(OPENSSL_ARM) || defined(OPENSSL_AARCH64))
|
|
|
|
// x86, x86_64, and the ARMs 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 // !NO_ASM && !STATIC_ARMCAP && (X86 || X86_64 || ARM || 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(BORINGSSL_DISPATCH_TEST)
|
|
|
|
// 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 uint8_t BORINGSSL_function_hit[7] = {0};
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if defined(OPENSSL_X86) || defined(OPENSSL_X86_64)
|
|
|
|
|
|
|
|
// This value must be explicitly initialized to zero. See similar comment above.
|
|
|
|
HIDDEN uint32_t OPENSSL_ia32cap_P[4] = {0};
|
|
|
|
|
Help the compiler dedup ia32cap and armcap accesses
https://boringssl-review.googlesource.com/c/boringssl/+/62585 made the
compiler emit multiple CRYPTO_library_init calls in functions which
dispatch between a tower of alternatives. Ideally, the compiler would
know that at most one call suffices.
There doesn't seem to be such an attribute, but we can get the same
effect with pure or const attributes. We tie init with returning the
capability vector. On Intel, because the vector is so large, we have to
go with a weaker version. Somewhat annoyingly, the getter must be
out-of-line, because otherwise the compiler inlines first and loses the
attribute.
I went with pure because we allow our unit tests to mutate
OPENSSL_armcap_P, which means the Arm one is, strictly speaking, pure,
not const. This slightly reduces optimization potential, but should
still allow deduping in most places. Confirmed that aes_init_key
now only calls a helper function once.
See discussion in
https://boringssl-review.googlesource.com/c/boringssl/+/62585/comment/26083b88_b3db2b75/
Bug: 35
Change-Id: I9bc464f0e5a0ed9601017a5037028f906693a137
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62985
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
1 year ago
|
|
|
uint32_t OPENSSL_get_ia32cap(int idx) {
|
|
|
|
CRYPTO_library_init();
|
|
|
|
return OPENSSL_ia32cap_P[idx];
|
|
|
|
}
|
|
|
|
|
|
|
|
#elif defined(OPENSSL_ARM) || defined(OPENSSL_AARCH64)
|
|
|
|
|
|
|
|
#include <openssl/arm_arch.h>
|
|
|
|
|
|
|
|
#if defined(OPENSSL_STATIC_ARMCAP)
|
|
|
|
|
Switch __ARM_FEATURE_CRYPTO to __ARM_FEATURE_{AES,SHA2}.
The latest version of ACLE splits __ARM_FEATURE_CRYPTO into two defines
to reflect that, starting ARMv8.2, the cryptography extension can
include {AES,PMULL} and {SHA1,SHA256} separately.
Also standardize on __ARM_NEON, which is the recommended symbol from
ACLE, and the only one defined on non-Apple aarch64 targets. Digging
through GCC history, __ARM_NEON__ is a bit older. __ARM_NEON was added
in GCC's 9e94a7fc5ab770928b9e6a2b74e292d35b4c94da from 2012, part of GCC
4.8.0.
I suspect we can stop paying attention to __ARM_NEON__ at this point,
but I've left both working for now. __ARM_FEATURE_{AES,SHA2} is definite
too new to fully replace __ARM_FEATURE_CRYPTO.
Tested on Linux that -march=armv8-a+aes now also drops the fallback AES
code. Previously, we would pick up -march=armv8-a+crypto, but not
-march=armv8-a+aes. Also tested that, on an OPENSSL_STATIC_ARMCAP build,
-march=armv8-a+sha2 sets the SHA-1 and SHA-256 features.
Change-Id: I749bdbc501ba2da23177ddb823547efcd77e5c98
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50847
Reviewed-by: Adam Langley <agl@google.com>
3 years ago
|
|
|
// See ARM ACLE for the definitions of these macros. Note |__ARM_FEATURE_AES|
|
|
|
|
// covers both AES and PMULL and |__ARM_FEATURE_SHA2| covers SHA-1 and SHA-256.
|
|
|
|
// https://developer.arm.com/architectures/system-architectures/software-standards/acle
|
|
|
|
// https://github.com/ARM-software/acle/issues/152
|
|
|
|
//
|
|
|
|
// TODO(davidben): Do we still need |OPENSSL_STATIC_ARMCAP_*| or are the
|
|
|
|
// standard flags and -march sufficient?
|
|
|
|
HIDDEN uint32_t OPENSSL_armcap_P =
|
Switch __ARM_FEATURE_CRYPTO to __ARM_FEATURE_{AES,SHA2}.
The latest version of ACLE splits __ARM_FEATURE_CRYPTO into two defines
to reflect that, starting ARMv8.2, the cryptography extension can
include {AES,PMULL} and {SHA1,SHA256} separately.
Also standardize on __ARM_NEON, which is the recommended symbol from
ACLE, and the only one defined on non-Apple aarch64 targets. Digging
through GCC history, __ARM_NEON__ is a bit older. __ARM_NEON was added
in GCC's 9e94a7fc5ab770928b9e6a2b74e292d35b4c94da from 2012, part of GCC
4.8.0.
I suspect we can stop paying attention to __ARM_NEON__ at this point,
but I've left both working for now. __ARM_FEATURE_{AES,SHA2} is definite
too new to fully replace __ARM_FEATURE_CRYPTO.
Tested on Linux that -march=armv8-a+aes now also drops the fallback AES
code. Previously, we would pick up -march=armv8-a+crypto, but not
-march=armv8-a+aes. Also tested that, on an OPENSSL_STATIC_ARMCAP build,
-march=armv8-a+sha2 sets the SHA-1 and SHA-256 features.
Change-Id: I749bdbc501ba2da23177ddb823547efcd77e5c98
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50847
Reviewed-by: Adam Langley <agl@google.com>
3 years ago
|
|
|
#if defined(OPENSSL_STATIC_ARMCAP_NEON) || defined(__ARM_NEON)
|
|
|
|
ARMV7_NEON |
|
|
|
|
#endif
|
Switch __ARM_FEATURE_CRYPTO to __ARM_FEATURE_{AES,SHA2}.
The latest version of ACLE splits __ARM_FEATURE_CRYPTO into two defines
to reflect that, starting ARMv8.2, the cryptography extension can
include {AES,PMULL} and {SHA1,SHA256} separately.
Also standardize on __ARM_NEON, which is the recommended symbol from
ACLE, and the only one defined on non-Apple aarch64 targets. Digging
through GCC history, __ARM_NEON__ is a bit older. __ARM_NEON was added
in GCC's 9e94a7fc5ab770928b9e6a2b74e292d35b4c94da from 2012, part of GCC
4.8.0.
I suspect we can stop paying attention to __ARM_NEON__ at this point,
but I've left both working for now. __ARM_FEATURE_{AES,SHA2} is definite
too new to fully replace __ARM_FEATURE_CRYPTO.
Tested on Linux that -march=armv8-a+aes now also drops the fallback AES
code. Previously, we would pick up -march=armv8-a+crypto, but not
-march=armv8-a+aes. Also tested that, on an OPENSSL_STATIC_ARMCAP build,
-march=armv8-a+sha2 sets the SHA-1 and SHA-256 features.
Change-Id: I749bdbc501ba2da23177ddb823547efcd77e5c98
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50847
Reviewed-by: Adam Langley <agl@google.com>
3 years ago
|
|
|
#if defined(OPENSSL_STATIC_ARMCAP_AES) || defined(__ARM_FEATURE_AES)
|
|
|
|
ARMV8_AES |
|
|
|
|
#endif
|
Switch __ARM_FEATURE_CRYPTO to __ARM_FEATURE_{AES,SHA2}.
The latest version of ACLE splits __ARM_FEATURE_CRYPTO into two defines
to reflect that, starting ARMv8.2, the cryptography extension can
include {AES,PMULL} and {SHA1,SHA256} separately.
Also standardize on __ARM_NEON, which is the recommended symbol from
ACLE, and the only one defined on non-Apple aarch64 targets. Digging
through GCC history, __ARM_NEON__ is a bit older. __ARM_NEON was added
in GCC's 9e94a7fc5ab770928b9e6a2b74e292d35b4c94da from 2012, part of GCC
4.8.0.
I suspect we can stop paying attention to __ARM_NEON__ at this point,
but I've left both working for now. __ARM_FEATURE_{AES,SHA2} is definite
too new to fully replace __ARM_FEATURE_CRYPTO.
Tested on Linux that -march=armv8-a+aes now also drops the fallback AES
code. Previously, we would pick up -march=armv8-a+crypto, but not
-march=armv8-a+aes. Also tested that, on an OPENSSL_STATIC_ARMCAP build,
-march=armv8-a+sha2 sets the SHA-1 and SHA-256 features.
Change-Id: I749bdbc501ba2da23177ddb823547efcd77e5c98
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50847
Reviewed-by: Adam Langley <agl@google.com>
3 years ago
|
|
|
#if defined(OPENSSL_STATIC_ARMCAP_PMULL) || defined(__ARM_FEATURE_AES)
|
|
|
|
ARMV8_PMULL |
|
|
|
|
#endif
|
|
|
|
#if defined(OPENSSL_STATIC_ARMCAP_SHA1) || defined(__ARM_FEATURE_SHA2)
|
|
|
|
ARMV8_SHA1 |
|
|
|
|
#endif
|
Switch __ARM_FEATURE_CRYPTO to __ARM_FEATURE_{AES,SHA2}.
The latest version of ACLE splits __ARM_FEATURE_CRYPTO into two defines
to reflect that, starting ARMv8.2, the cryptography extension can
include {AES,PMULL} and {SHA1,SHA256} separately.
Also standardize on __ARM_NEON, which is the recommended symbol from
ACLE, and the only one defined on non-Apple aarch64 targets. Digging
through GCC history, __ARM_NEON__ is a bit older. __ARM_NEON was added
in GCC's 9e94a7fc5ab770928b9e6a2b74e292d35b4c94da from 2012, part of GCC
4.8.0.
I suspect we can stop paying attention to __ARM_NEON__ at this point,
but I've left both working for now. __ARM_FEATURE_{AES,SHA2} is definite
too new to fully replace __ARM_FEATURE_CRYPTO.
Tested on Linux that -march=armv8-a+aes now also drops the fallback AES
code. Previously, we would pick up -march=armv8-a+crypto, but not
-march=armv8-a+aes. Also tested that, on an OPENSSL_STATIC_ARMCAP build,
-march=armv8-a+sha2 sets the SHA-1 and SHA-256 features.
Change-Id: I749bdbc501ba2da23177ddb823547efcd77e5c98
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50847
Reviewed-by: Adam Langley <agl@google.com>
3 years ago
|
|
|
#if defined(OPENSSL_STATIC_ARMCAP_SHA256) || defined(__ARM_FEATURE_SHA2)
|
|
|
|
ARMV8_SHA256 |
|
|
|
|
#endif
|
Enable SHA-512 ARM acceleration when available.
This imports the changes to sha512-armv8.pl from
upstream's af0fcf7b4668218b24d9250b95e0b96939ccb4d1.
Tweaks needed:
- Add an explicit .text because we put .LK$BITS in .rodata for XOM
- .LK$bits and code are in separate sections, so use adrp/add instead of
plain adr
- Where glibc needs feature flags to *enable* pthread_rwlock, Apple
interprets _XOPEN_SOURCE as a request to *disable* Apple extensions.
Tighten the condition on the _XOPEN_SOURCE check.
Added support for macOS and Linux, tested manually on an ARM Mac and a
VM, respectively. Fuchsia and Windows do not currently have APIs to
expose this bit, so I've left in TODOs. Benchmarks from an Apple M1 Max:
Before:
Did 4647000 SHA-512 (16 bytes) operations in 1000103us (74.3 MB/sec)
Did 1614000 SHA-512 (256 bytes) operations in 1000379us (413.0 MB/sec)
Did 439000 SHA-512 (1350 bytes) operations in 1001694us (591.6 MB/sec)
Did 76000 SHA-512 (8192 bytes) operations in 1011821us (615.3 MB/sec)
Did 39000 SHA-512 (16384 bytes) operations in 1024311us (623.8 MB/sec)
After:
Did 10369000 SHA-512 (16 bytes) operations in 1000088us (165.9 MB/sec) [+123.1%]
Did 3650000 SHA-512 (256 bytes) operations in 1000079us (934.3 MB/sec) [+126.2%]
Did 1029000 SHA-512 (1350 bytes) operations in 1000521us (1388.4 MB/sec) [+134.7%]
Did 175000 SHA-512 (8192 bytes) operations in 1001874us (1430.9 MB/sec) [+132.5%]
Did 89000 SHA-512 (16384 bytes) operations in 1010314us (1443.3 MB/sec) [+131.4%]
(This doesn't seem to change the overall SHA-256 vs SHA-512 performance
question on ARM, when hashing perf matters. SHA-256 on the same chip
gets up to 2454.6 MB/s.)
In terms of build coverage, for now, we'll have build coverage
everywhere and test coverage on Chromium, which runs this code on macOS
CI. We should request a macOS ARM64 bot for our standalone CI. Longer
term, we need a QEMU-based builder to test various features. QEMU seems
to have pretty good coverage of all this, which will at least give us
Linux.
I haven't added an OPENSSL_STATIC_ARMCAP_SHA512 for now. Instead, we
just look at the standard __ARM_FEATURE_SHA512 define. Strangely, the
corresponding -march tag is not sha512. Neither GCC and nor Clang have
-march=armv8-a+sha512. Instead, -march=armv8-a+sha3 implies both
__ARM_FEATURE_SHA3 and __ARM_FEATURE_SHA512! Yet everything else seems
to describe the SHA512 extension as separate from SHA3.
https://developer.arm.com/architectures/system-architectures/software-standards/acle
Update-Note: Consumers with a different build setup may need to
limit -D_XOPEN_SOURCE=700 to Linux or non-Apple platforms. Otherwise,
<sys/types.h> won't define some typedef needed by <sys/sysctl.h>. If you
see a build error about u_char, etc., being undefined in some system
header, that is probably the cause.
Change-Id: Ia213d3796b84c71b7966bb68e0aec92e5d7d26f0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50807
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
3 years ago
|
|
|
#if defined(__ARM_FEATURE_SHA512)
|
|
|
|
ARMV8_SHA512 |
|
|
|
|
#endif
|
|
|
|
0;
|
|
|
|
|
|
|
|
#else
|
|
|
|
HIDDEN uint32_t OPENSSL_armcap_P = 0;
|
|
|
|
|
|
|
|
uint32_t *OPENSSL_get_armcap_pointer_for_test(void) {
|
Help the compiler dedup ia32cap and armcap accesses
https://boringssl-review.googlesource.com/c/boringssl/+/62585 made the
compiler emit multiple CRYPTO_library_init calls in functions which
dispatch between a tower of alternatives. Ideally, the compiler would
know that at most one call suffices.
There doesn't seem to be such an attribute, but we can get the same
effect with pure or const attributes. We tie init with returning the
capability vector. On Intel, because the vector is so large, we have to
go with a weaker version. Somewhat annoyingly, the getter must be
out-of-line, because otherwise the compiler inlines first and loses the
attribute.
I went with pure because we allow our unit tests to mutate
OPENSSL_armcap_P, which means the Arm one is, strictly speaking, pure,
not const. This slightly reduces optimization potential, but should
still allow deduping in most places. Confirmed that aes_init_key
now only calls a helper function once.
See discussion in
https://boringssl-review.googlesource.com/c/boringssl/+/62585/comment/26083b88_b3db2b75/
Bug: 35
Change-Id: I9bc464f0e5a0ed9601017a5037028f906693a137
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62985
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
1 year ago
|
|
|
CRYPTO_library_init();
|
|
|
|
return &OPENSSL_armcap_P;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
Help the compiler dedup ia32cap and armcap accesses
https://boringssl-review.googlesource.com/c/boringssl/+/62585 made the
compiler emit multiple CRYPTO_library_init calls in functions which
dispatch between a tower of alternatives. Ideally, the compiler would
know that at most one call suffices.
There doesn't seem to be such an attribute, but we can get the same
effect with pure or const attributes. We tie init with returning the
capability vector. On Intel, because the vector is so large, we have to
go with a weaker version. Somewhat annoyingly, the getter must be
out-of-line, because otherwise the compiler inlines first and loses the
attribute.
I went with pure because we allow our unit tests to mutate
OPENSSL_armcap_P, which means the Arm one is, strictly speaking, pure,
not const. This slightly reduces optimization potential, but should
still allow deduping in most places. Confirmed that aes_init_key
now only calls a helper function once.
See discussion in
https://boringssl-review.googlesource.com/c/boringssl/+/62585/comment/26083b88_b3db2b75/
Bug: 35
Change-Id: I9bc464f0e5a0ed9601017a5037028f906693a137
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62985
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
1 year ago
|
|
|
uint32_t OPENSSL_get_armcap(void) {
|
|
|
|
CRYPTO_library_init();
|
|
|
|
return OPENSSL_armcap_P;
|
|
|
|
}
|
|
|
|
|
|
|
|
#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
|
|
|
|
}
|
|
|
|
|
|
|
|
void CRYPTO_pre_sandbox_init(void) {
|
|
|
|
// Read from /proc/cpuinfo if needed.
|
|
|
|
CRYPTO_library_init();
|
|
|
|
// Open /dev/urandom if needed.
|
|
|
|
CRYPTO_init_sysrand();
|
|
|
|
// Set up MADV_WIPEONFORK state if needed.
|
|
|
|
CRYPTO_get_fork_generation();
|
|
|
|
}
|
|
|
|
|
|
|
|
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";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned long SSLeay(void) { return OPENSSL_VERSION_NUMBER; }
|
|
|
|
|
|
|
|
unsigned long OpenSSL_version_num(void) { return OPENSSL_VERSION_NUMBER; }
|
|
|
|
|
|
|
|
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) {}
|
|
|
|
|
|
|
|
int OPENSSL_init_crypto(uint64_t opts, const OPENSSL_INIT_SETTINGS *settings) {
|
|
|
|
CRYPTO_library_init();
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
void OPENSSL_cleanup(void) {}
|