kris/boringssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
2eb2889702
boringssl/crypto/cpu-aarch64-linux.c

62 lines
1.8 KiB
C
Raw Normal View History

Rewrite ARM feature detection. This removes the thread-unsafe SIGILL-based detection and the multi-consumer-hostile CRYPTO_set_NEON_capable API. (Changing OPENSSL_armcap_P after initialization is likely to cause problems.) The right way to detect ARM features on Linux is getauxval. On aarch64, we should be able to rely on this, so use it straight. Split this out into its own file. The #ifdefs in the old cpu-arm.c meant it shared all but no code with its arm counterpart anyway. Unfortunately, various versions of Android have different missing APIs, so, on arm, we need a series of workarounds. Previously, we used a SIGILL fallback based on OpenSSL's logic, but this is inherently not thread-safe. (SIGILL also does not tell us if the OS knows how to save and restore NEON state.) Instead, base the behavior on Android NDK's cpu-features library, what Chromium currently uses with CRYPTO_set_NEON_capable: - Android before API level 20 does not provide getauxval. Where missing, we can read from /proc/self/auxv. - On some versions of Android, /proc/self/auxv is also not readable, so use /proc/cpuinfo's Features line. - Linux only advertises optional features in /proc/cpuinfo. ARMv8 makes NEON mandatory, so /proc/cpuinfo can't be used without additional effort. Finally, we must blacklist a particular chip because the NEON unit is broken (https://crbug.com/341598). Unfortunately, this means CRYPTO_library_init now depends on /proc being available, which will require some care with Chromium's sandbox. The simplest solution is to just call CRYPTO_library_init before entering the sandbox. It's worth noting that Chromium's current EnsureOpenSSLInit function already depends on /proc/cpuinfo to detect the broken CPU, by way of base::CPU. android_getCpuFeatures also interally depends on it. We were already relying on both of those being stateful and primed prior to entering the sandbox. BUG=chromium:589200 Change-Id: Ic5d1c341aab5a614eb129d8aa5ada2809edd6af8 Reviewed-on: https://boringssl-review.googlesource.com/7506 Reviewed-by: David Benjamin <davidben@google.com>
2016-03-01 22:35:47 +00:00
/* Copyright (c) 2016, 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/cpu.h>
#if defined(OPENSSL_AARCH64) && !defined(OPENSSL_STATIC_ARMCAP)
#include <sys/auxv.h>
#include <openssl/arm_arch.h>
#include "internal.h"
extern uint32_t OPENSSL_armcap_P;
void OPENSSL_cpuid_setup(void) {
unsigned long hwcap = getauxval(AT_HWCAP);
Run the comment converter on libcrypto. crypto/{asn1,x509,x509v3,pem} were skipped as they are still OpenSSL style. Change-Id: I3cd9a60e1cb483a981aca325041f3fbce294247c Reviewed-on: https://boringssl-review.googlesource.com/19504 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-08-18 19:06:02 +01:00
// See /usr/include/asm/hwcap.h on an aarch64 installation for the source of
// these values.
Rewrite ARM feature detection. This removes the thread-unsafe SIGILL-based detection and the multi-consumer-hostile CRYPTO_set_NEON_capable API. (Changing OPENSSL_armcap_P after initialization is likely to cause problems.) The right way to detect ARM features on Linux is getauxval. On aarch64, we should be able to rely on this, so use it straight. Split this out into its own file. The #ifdefs in the old cpu-arm.c meant it shared all but no code with its arm counterpart anyway. Unfortunately, various versions of Android have different missing APIs, so, on arm, we need a series of workarounds. Previously, we used a SIGILL fallback based on OpenSSL's logic, but this is inherently not thread-safe. (SIGILL also does not tell us if the OS knows how to save and restore NEON state.) Instead, base the behavior on Android NDK's cpu-features library, what Chromium currently uses with CRYPTO_set_NEON_capable: - Android before API level 20 does not provide getauxval. Where missing, we can read from /proc/self/auxv. - On some versions of Android, /proc/self/auxv is also not readable, so use /proc/cpuinfo's Features line. - Linux only advertises optional features in /proc/cpuinfo. ARMv8 makes NEON mandatory, so /proc/cpuinfo can't be used without additional effort. Finally, we must blacklist a particular chip because the NEON unit is broken (https://crbug.com/341598). Unfortunately, this means CRYPTO_library_init now depends on /proc being available, which will require some care with Chromium's sandbox. The simplest solution is to just call CRYPTO_library_init before entering the sandbox. It's worth noting that Chromium's current EnsureOpenSSLInit function already depends on /proc/cpuinfo to detect the broken CPU, by way of base::CPU. android_getCpuFeatures also interally depends on it. We were already relying on both of those being stateful and primed prior to entering the sandbox. BUG=chromium:589200 Change-Id: Ic5d1c341aab5a614eb129d8aa5ada2809edd6af8 Reviewed-on: https://boringssl-review.googlesource.com/7506 Reviewed-by: David Benjamin <davidben@google.com>
2016-03-01 22:35:47 +00:00
static const unsigned long kNEON = 1 << 1;
static const unsigned long kAES = 1 << 3;
static const unsigned long kPMULL = 1 << 4;
static const unsigned long kSHA1 = 1 << 5;
static const unsigned long kSHA256 = 1 << 6;
if ((hwcap & kNEON) == 0) {
Run the comment converter on libcrypto. crypto/{asn1,x509,x509v3,pem} were skipped as they are still OpenSSL style. Change-Id: I3cd9a60e1cb483a981aca325041f3fbce294247c Reviewed-on: https://boringssl-review.googlesource.com/19504 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-08-18 19:06:02 +01:00
// Matching OpenSSL, if NEON is missing, don't report other features
// either.
Rewrite ARM feature detection. This removes the thread-unsafe SIGILL-based detection and the multi-consumer-hostile CRYPTO_set_NEON_capable API. (Changing OPENSSL_armcap_P after initialization is likely to cause problems.) The right way to detect ARM features on Linux is getauxval. On aarch64, we should be able to rely on this, so use it straight. Split this out into its own file. The #ifdefs in the old cpu-arm.c meant it shared all but no code with its arm counterpart anyway. Unfortunately, various versions of Android have different missing APIs, so, on arm, we need a series of workarounds. Previously, we used a SIGILL fallback based on OpenSSL's logic, but this is inherently not thread-safe. (SIGILL also does not tell us if the OS knows how to save and restore NEON state.) Instead, base the behavior on Android NDK's cpu-features library, what Chromium currently uses with CRYPTO_set_NEON_capable: - Android before API level 20 does not provide getauxval. Where missing, we can read from /proc/self/auxv. - On some versions of Android, /proc/self/auxv is also not readable, so use /proc/cpuinfo's Features line. - Linux only advertises optional features in /proc/cpuinfo. ARMv8 makes NEON mandatory, so /proc/cpuinfo can't be used without additional effort. Finally, we must blacklist a particular chip because the NEON unit is broken (https://crbug.com/341598). Unfortunately, this means CRYPTO_library_init now depends on /proc being available, which will require some care with Chromium's sandbox. The simplest solution is to just call CRYPTO_library_init before entering the sandbox. It's worth noting that Chromium's current EnsureOpenSSLInit function already depends on /proc/cpuinfo to detect the broken CPU, by way of base::CPU. android_getCpuFeatures also interally depends on it. We were already relying on both of those being stateful and primed prior to entering the sandbox. BUG=chromium:589200 Change-Id: Ic5d1c341aab5a614eb129d8aa5ada2809edd6af8 Reviewed-on: https://boringssl-review.googlesource.com/7506 Reviewed-by: David Benjamin <davidben@google.com>
2016-03-01 22:35:47 +00:00
return;
}
OPENSSL_armcap_P |= ARMV7_NEON;
if (hwcap & kAES) {
OPENSSL_armcap_P |= ARMV8_AES;
}
if (hwcap & kPMULL) {
OPENSSL_armcap_P |= ARMV8_PMULL;
}
if (hwcap & kSHA1) {
OPENSSL_armcap_P |= ARMV8_SHA1;
}
if (hwcap & kSHA256) {
OPENSSL_armcap_P |= ARMV8_SHA256;
}
}
Run the comment converter on libcrypto. crypto/{asn1,x509,x509v3,pem} were skipped as they are still OpenSSL style. Change-Id: I3cd9a60e1cb483a981aca325041f3fbce294247c Reviewed-on: https://boringssl-review.googlesource.com/19504 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-08-18 19:06:02 +01:00
#endif // OPENSSL_AARCH64 && !OPENSSL_STATIC_ARMCAP
Reference in New Issue Copy Permalink