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

96 lines
3.3 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) 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. */
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
#ifndef OPENSSL_HEADER_CRYPTO_H
#define OPENSSL_HEADER_CRYPTO_H
#include <openssl/base.h>
Put the mem.h include back into crypto.h. 054e68267553e0b64975444741efa8099688d960 removed the compatibility include of mem.h in crypto.h. mem.h doesn't exist in upstream which defines these functions in crypto.h instead. The compatibility include should probably be restored to avoid causing all kinds of grief when porting consumers over. Change-Id: Idfe0f9b43ebee5df22bebfe0ed6dc85ec98b4de0 Reviewed-on: https://boringssl-review.googlesource.com/4530 Reviewed-by: Adam Langley <agl@google.com>
2015-04-24 15:15:31 +01:00
/* Upstream OpenSSL defines |OPENSSL_malloc|, etc., in crypto.h rather than
* mem.h. */
#include <openssl/mem.h>
Include thread.h from crypto.h, like OpenSSL. thread.h defines |CRYPTO_num_locks| and friends. Change-Id: Id28484d20226bf3ab49b2a75c48210167b96a2f3 Reviewed-on: https://boringssl-review.googlesource.com/5592 Reviewed-by: Adam Langley <agl@google.com>
2015-08-05 19:40:35 +01:00
/* Upstream OpenSSL defines |CRYPTO_LOCK|, etc., in crypto.h rather than
* thread.h. */
#include <openssl/thread.h>
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
#if defined(__cplusplus)
extern "C" {
#endif
/* crypto.h contains functions for initializing the crypto library. */
/* CRYPTO_library_init initializes the crypto library. It must be called if the
* library is built with BORINGSSL_NO_STATIC_INITIALIZER. Otherwise, it does
Document that CRYPTO_library_init may be called concurrently. This was fixed in 93a5b442964d9770b5faa0fb381a8c4f43e65abe, but it wasn't documented. Now that there are no pre-init functions to call like CRYPTO_set_neon_capable, one instance of BoringSSL may be safely shared between multiple consumers. As part of that, multiple consumers need to be able to call CRYPTO_library_init possibly redundantlyand possibly on different threads without synchronization. (Though there is still that static initializer nuisance. It would be nice to replace this with internal CRYPTO_once_t's and then CRYPTO_library_init need only be called to prime armcap for a sandbox. But one thing at a time.) Change-Id: I48430182d3649c8cf19082e34da24dee48e6119e Reviewed-on: https://boringssl-review.googlesource.com/7571 Reviewed-by: Emily Stark (Dunn) <estark@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-26 04:58:38 +00:00
* nothing and a static initializer is used instead. It is safe to call this
* function multiple times and concurrently from multiple threads.
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
*
* On some ARM configurations, this function may require filesystem access and
* should be called before entering a sandbox. */
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
OPENSSL_EXPORT void CRYPTO_library_init(void);
Add |CRYPTO_is_confidential_build|. In the past we have needed the ability to deploy security fixes to our frontend systems without leaking them in source code or in published binaries. This change adds a function that provides some infrastructure for supporting this in BoringSSL while meeting our internal build needs. We do not currently have any specific patch that requires this—this is purely preparation. Change-Id: I5c64839e86db4e5ea7419a38106d8f88b8e5987e Reviewed-on: https://boringssl-review.googlesource.com/7849 Reviewed-by: David Benjamin <davidben@google.com>
2016-05-03 17:16:21 +01:00
/* CRYPTO_is_confidential_build returns one if the linked version of BoringSSL
* has been built with the BORINGSSL_CONFIDENTIAL define and zero otherwise.
*
* This is used by some consumers to identify whether they are using an
* internal version of BoringSSL. */
OPENSSL_EXPORT int CRYPTO_is_confidential_build(void);
Add CRYPTO_has_asm. This function will return whether BoringSSL was built with OPENSSL_NO_ASM. This will allow us to write a test in our internal codebase which asserts that normal builds should always have assembly code included. Change-Id: Ib226bf63199022f0039d590edd50c0cc823927b9 Reviewed-on: https://boringssl-review.googlesource.com/7960 Reviewed-by: David Benjamin <davidben@google.com>
2016-05-16 21:44:40 +01:00
/* CRYPTO_has_asm returns one unless BoringSSL was built with OPENSSL_NO_ASM,
* in which case it returns zero. */
OPENSSL_EXPORT int CRYPTO_has_asm(void);
First part of the FIPS module. Change-Id: Ic3a91ccd2c8cdc364740f256fdb8a7ff66177947 Reviewed-on: https://boringssl-review.googlesource.com/14506 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
2017-04-04 22:21:43 +01:00
/* FIPS_mode returns zero unless BoringSSL is built with BORINGSSL_FIPS, in
* which case it returns one. */
OPENSSL_EXPORT int FIPS_mode(void);
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
Compatibility changes for wpa_supplicant and OpenSSH. OpenSSH, especially, does some terrible things that mean that it needs the EVP_CIPHER structure to be exposed ☹. Damian is open to a better API to replace this, but only if OpenSSL agree too. Either way, it won't be happening soon. Change-Id: I393b7a6af6694d4d2fe9ebcccd40286eff4029bd Reviewed-on: https://boringssl-review.googlesource.com/4330 Reviewed-by: Adam Langley <agl@google.com>
2015-04-13 22:34:17 +01:00
/* Deprecated functions. */
Tweaks for node.js node.js is, effectively, another bindings library. However, it's better written than most and, with these changes, only a couple of tiny fixes are needed in node.js. Some of these changes are a little depressing however so we'll need to push node.js to use APIs where possible. Changes: ∙ Support verify_recover. This is very obscure and the motivation appears to be https://github.com/nodejs/node/issues/477 – where it's not clear that anyone understands what it means :( ∙ Add a few, no-op #defines ∙ Add some members to |SSL_CTX| and |SSL| – node.js needs to not reach into these structs in the future. ∙ Add EC_get_builtin_curves. ∙ Add EVP_[CIPHER|MD]_do_all_sorted – these functions are limited to decrepit. Change-Id: I9a3566054260d6c4db9d430beb7c46cc970a9d46 Reviewed-on: https://boringssl-review.googlesource.com/6952 Reviewed-by: Adam Langley <agl@google.com>
2016-01-24 23:58:39 +00:00
/* OPENSSL_VERSION_TEXT contains a string the identifies the version of
* “OpenSSL”. node.js requires a version number in this text. */
#define OPENSSL_VERSION_TEXT "OpenSSL 1.0.2 (compatible; BoringSSL)"
Compatibility changes for wpa_supplicant and OpenSSH. OpenSSH, especially, does some terrible things that mean that it needs the EVP_CIPHER structure to be exposed ☹. Damian is open to a better API to replace this, but only if OpenSSL agree too. Either way, it won't be happening soon. Change-Id: I393b7a6af6694d4d2fe9ebcccd40286eff4029bd Reviewed-on: https://boringssl-review.googlesource.com/4330 Reviewed-by: Adam Langley <agl@google.com>
2015-04-13 22:34:17 +01:00
#define SSLEAY_VERSION 0
/* SSLeay_version is a compatibility function that returns the string
* "BoringSSL". */
OPENSSL_EXPORT const char *SSLeay_version(int unused);
Fix |SSLeay|. SSLeay is a compatibility function for OpenSSL, but I got it wrong. It doesn't return a string, it returns a number. This doesn't end up making any difference, but it fixes a warning when building OpenSSH. Change-Id: I327ab4f70313c93c18f81d8804ba4acdc3bc1a4a Reviewed-on: https://boringssl-review.googlesource.com/4811 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2015-05-20 00:30:20 +01:00
/* SSLeay is a compatibility function that returns OPENSSL_VERSION_NUMBER from
* base.h. */
OPENSSL_EXPORT unsigned long SSLeay(void);
Compatibility changes for wpa_supplicant and OpenSSH. OpenSSH, especially, does some terrible things that mean that it needs the EVP_CIPHER structure to be exposed ☹. Damian is open to a better API to replace this, but only if OpenSSL agree too. Either way, it won't be happening soon. Change-Id: I393b7a6af6694d4d2fe9ebcccd40286eff4029bd Reviewed-on: https://boringssl-review.googlesource.com/4330 Reviewed-by: Adam Langley <agl@google.com>
2015-04-13 22:34:17 +01:00
Add no-op functions |CRYPTO_malloc_init| and |ENGINE_load_builtin_engines|. This reduces the impact on Netty. See https://github.com/Scottmitch/netty-tcnative/commit/904b84ce41fc44dd1d3955df69912d91906c9877#commitcomment-12159877 Change-Id: I22f9e1edaeb9e721326867ae2b4f3da2c5441437 Reviewed-on: https://boringssl-review.googlesource.com/5535 Reviewed-by: Adam Langley <alangley@gmail.com>
2015-08-02 17:35:44 +01:00
/* CRYPTO_malloc_init returns one. */
OPENSSL_EXPORT int CRYPTO_malloc_init(void);
/* ENGINE_load_builtin_engines does nothing. */
OPENSSL_EXPORT void ENGINE_load_builtin_engines(void);
Add no-op function ENGINE_register_all_complete. libssh2 expects this function. Change-Id: Ie2d6ceb25d1b633e1363e82f8a6c187b75a4319f Reviewed-on: https://boringssl-review.googlesource.com/8735 Reviewed-by: David Benjamin <davidben@google.com>
2016-07-12 18:26:56 +01:00
/* ENGINE_register_all_complete returns one. */
OPENSSL_EXPORT int ENGINE_register_all_complete(void);
Add a few more no-op stubs for cURL compatibility. With these stubs, cURL should not need any BoringSSL #ifdefs at all, except for their OCSP #ifdefs (which can switch to the more generally useful OPENSSL_NO_OCSP) and the workaround for wincrypt.h macro collisions. That we intentionally leave to the consumer rather than add a partial hack that makes the build sensitive to include order. (I'll send them a patch upstream once this cycles in.) Change-Id: I815fe67e51e80e9aafa9b91ae68867ca1ff1d623 Reviewed-on: https://boringssl-review.googlesource.com/6980 Reviewed-by: Adam Langley <agl@google.com>
2016-01-26 06:09:19 +00:00
/* OPENSSL_load_builtin_modules does nothing. */
OPENSSL_EXPORT void OPENSSL_load_builtin_modules(void);
Compatibility changes for wpa_supplicant and OpenSSH. OpenSSH, especially, does some terrible things that mean that it needs the EVP_CIPHER structure to be exposed ☹. Damian is open to a better API to replace this, but only if OpenSSL agree too. Either way, it won't be happening soon. Change-Id: I393b7a6af6694d4d2fe9ebcccd40286eff4029bd Reviewed-on: https://boringssl-review.googlesource.com/4330 Reviewed-by: Adam Langley <agl@google.com>
2015-04-13 22:34:17 +01:00
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
#if defined(__cplusplus)
} /* extern C */
#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
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
#endif /* OPENSSL_HEADER_CRYPTO_H */
Reference in New Issue Copy Permalink