2014-06-20 12:00:00 -07:00
|
|
|
/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* This package is an SSL implementation written
|
|
|
|
* by Eric Young (eay@cryptsoft.com).
|
|
|
|
* The implementation was written so as to conform with Netscapes SSL.
|
|
|
|
*
|
|
|
|
* This library is free for commercial and non-commercial use as long as
|
|
|
|
* the following conditions are aheared to. The following conditions
|
|
|
|
* apply to all code found in this distribution, be it the RC4, RSA,
|
|
|
|
* lhash, DES, etc., code; not just the SSL code. The SSL documentation
|
|
|
|
* included with this distribution is covered by the same copyright terms
|
|
|
|
* except that the holder is Tim Hudson (tjh@cryptsoft.com).
|
|
|
|
*
|
|
|
|
* Copyright remains Eric Young's, and as such any Copyright notices in
|
|
|
|
* the code are not to be removed.
|
|
|
|
* If this package is used in a product, Eric Young should be given attribution
|
|
|
|
* as the author of the parts of the library used.
|
|
|
|
* This can be in the form of a textual message at program startup or
|
|
|
|
* in documentation (online or textual) provided with the package.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
* 3. All advertising materials mentioning features or use of this software
|
|
|
|
* must display the following acknowledgement:
|
|
|
|
* "This product includes cryptographic software written by
|
|
|
|
* Eric Young (eay@cryptsoft.com)"
|
|
|
|
* The word 'cryptographic' can be left out if the rouines from the library
|
|
|
|
* being used are not cryptographic related :-).
|
|
|
|
* 4. If you include any Windows specific code (or a derivative thereof) from
|
|
|
|
* the apps directory (application code) you must include an acknowledgement:
|
|
|
|
* "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
*
|
|
|
|
* The licence and distribution terms for any publically available version or
|
|
|
|
* derivative of this code cannot be changed. i.e. this code cannot simply be
|
|
|
|
* copied and put under another distribution licence
|
|
|
|
* [including the GNU Public Licence.]
|
|
|
|
*/
|
|
|
|
/* ====================================================================
|
|
|
|
* Copyright (c) 1998-2001 The OpenSSL Project. All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
*
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
*
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in
|
|
|
|
* the documentation and/or other materials provided with the
|
|
|
|
* distribution.
|
|
|
|
*
|
|
|
|
* 3. All advertising materials mentioning features or use of this
|
|
|
|
* software must display the following acknowledgment:
|
|
|
|
* "This product includes software developed by the OpenSSL Project
|
|
|
|
* for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
|
|
|
|
*
|
|
|
|
* 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
|
|
|
|
* endorse or promote products derived from this software without
|
|
|
|
* prior written permission. For written permission, please contact
|
|
|
|
* openssl-core@openssl.org.
|
|
|
|
*
|
|
|
|
* 5. Products derived from this software may not be called "OpenSSL"
|
|
|
|
* nor may "OpenSSL" appear in their names without prior written
|
|
|
|
* permission of the OpenSSL Project.
|
|
|
|
*
|
|
|
|
* 6. Redistributions of any form whatsoever must retain the following
|
|
|
|
* acknowledgment:
|
|
|
|
* "This product includes software developed by the OpenSSL Project
|
|
|
|
* for use in the OpenSSL Toolkit (http://www.openssl.org/)"
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
|
|
|
|
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
|
|
|
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
|
|
|
|
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
|
|
|
|
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
|
|
|
|
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
|
|
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
|
|
|
|
* OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
* ====================================================================
|
|
|
|
*
|
|
|
|
* This product includes cryptographic software written by Eric Young
|
|
|
|
* (eay@cryptsoft.com). This product includes software written by Tim
|
|
|
|
* Hudson (tjh@cryptsoft.com). */
|
|
|
|
|
|
|
|
#ifndef OPENSSL_HEADER_CRYPTO_INTERNAL_H
|
|
|
|
#define OPENSSL_HEADER_CRYPTO_INTERNAL_H
|
|
|
|
|
2021-05-02 14:42:05 -07:00
|
|
|
#include <ring-core/base.h> // Must be first.
|
2018-11-15 13:13:17 -10:00
|
|
|
|
2023-10-30 14:02:06 -07:00
|
|
|
#include "ring-core/arm_arch.h"
|
2021-05-02 14:42:05 -07:00
|
|
|
#include "ring-core/check.h"
|
2016-01-21 14:57:17 -10:00
|
|
|
|
2021-08-12 19:30:16 -07:00
|
|
|
#if defined(__clang__)
|
|
|
|
// Don't require prototypes for functions defined in C that are only
|
|
|
|
// used from Rust.
|
|
|
|
#pragma GCC diagnostic ignored "-Wmissing-prototypes"
|
|
|
|
#endif
|
|
|
|
|
2018-01-17 13:39:52 +01:00
|
|
|
#if defined(__GNUC__) && \
|
|
|
|
(__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__) < 40800
|
|
|
|
// |alignas| and |alignof| were added in C11. GCC added support in version 4.8.
|
|
|
|
// Testing for __STDC_VERSION__/__cplusplus doesn't work because 4.7 already
|
|
|
|
// reports support for C11.
|
|
|
|
#define alignas(x) __attribute__ ((aligned (x)))
|
2019-07-22 12:03:09 -10:00
|
|
|
#elif defined(_MSC_VER) && !defined(__clang__)
|
2016-01-17 20:12:57 -10:00
|
|
|
#define alignas(x) __declspec(align(x))
|
2015-10-04 18:38:54 -10:00
|
|
|
#else
|
|
|
|
#include <stdalign.h>
|
|
|
|
#endif
|
2014-06-20 12:00:00 -07:00
|
|
|
|
2024-01-11 15:15:22 -08:00
|
|
|
#if defined(__clang__) || defined(__GNUC__)
|
|
|
|
#define RING_NOINLINE __attribute__((noinline))
|
|
|
|
#elif defined(_MSC_VER)
|
|
|
|
#define RING_NOINLINE __declspec(noinline)
|
|
|
|
#else
|
|
|
|
#define RING_NOINLINE
|
|
|
|
#endif
|
|
|
|
|
2020-06-10 15:50:32 -05:00
|
|
|
// Some C compilers require a useless cast when dealing with arrays for the
|
|
|
|
// reason explained in
|
|
|
|
// https://gustedt.wordpress.com/2011/02/12/const-and-arrays/
|
|
|
|
#if defined(__clang__) || defined(_MSC_VER)
|
2021-05-02 14:42:05 -07:00
|
|
|
#define RING_CORE_POINTLESS_ARRAY_CONST_CAST(cast)
|
2020-06-10 15:50:32 -05:00
|
|
|
#else
|
2021-05-02 14:42:05 -07:00
|
|
|
#define RING_CORE_POINTLESS_ARRAY_CONST_CAST(cast) cast
|
2020-06-10 15:50:32 -05:00
|
|
|
#endif
|
|
|
|
|
2023-09-29 17:46:43 -07:00
|
|
|
// `uint8_t` isn't guaranteed to be 'unsigned char' and only 'char' and
|
|
|
|
// 'unsigned char' are allowed to alias according to ISO C.
|
|
|
|
typedef unsigned char aliasing_uint8_t;
|
2014-11-03 18:51:20 -08:00
|
|
|
|
2017-12-07 21:11:24 -05:00
|
|
|
#if (!defined(_MSC_VER) || defined(__clang__)) && defined(OPENSSL_64_BIT)
|
|
|
|
#define BORINGSSL_HAS_UINT128
|
2016-01-26 15:16:37 -10:00
|
|
|
typedef __int128_t int128_t;
|
|
|
|
typedef __uint128_t uint128_t;
|
|
|
|
#endif
|
|
|
|
|
2023-09-28 18:14:14 -07:00
|
|
|
// Pointer utility functions.
|
|
|
|
|
|
|
|
// buffers_alias returns one if |a| and |b| alias and zero otherwise.
|
2023-05-24 16:23:59 +00:00
|
|
|
static inline int buffers_alias(const void *a, size_t a_bytes,
|
|
|
|
const void *b, size_t b_bytes) {
|
2023-09-28 18:14:14 -07:00
|
|
|
// Cast |a| and |b| to integers. In C, pointer comparisons between unrelated
|
|
|
|
// objects are undefined whereas pointer to integer conversions are merely
|
|
|
|
// implementation-defined. We assume the implementation defined it in a sane
|
|
|
|
// way.
|
|
|
|
uintptr_t a_u = (uintptr_t)a;
|
|
|
|
uintptr_t b_u = (uintptr_t)b;
|
2023-05-24 16:23:59 +00:00
|
|
|
return a_u + a_bytes > b_u && b_u + b_bytes > a_u;
|
2023-09-28 18:14:14 -07:00
|
|
|
}
|
|
|
|
|
2016-01-26 15:16:37 -10:00
|
|
|
|
2017-08-18 14:06:02 -04:00
|
|
|
// Constant-time utility functions.
|
|
|
|
//
|
|
|
|
// The following methods return a bitmask of all ones (0xff...f) for true and 0
|
|
|
|
// for false. This is useful for choosing a value based on the result of a
|
|
|
|
// conditional in constant time. For example,
|
|
|
|
//
|
|
|
|
// if (a < b) {
|
|
|
|
// c = a;
|
|
|
|
// } else {
|
|
|
|
// c = b;
|
|
|
|
// }
|
|
|
|
//
|
|
|
|
// can be written as
|
|
|
|
//
|
2023-09-28 18:11:05 -07:00
|
|
|
// crypto_word_t lt = constant_time_lt_w(a, b);
|
2017-08-18 14:06:02 -04:00
|
|
|
// c = constant_time_select_w(lt, a, b);
|
|
|
|
|
2023-09-28 18:33:16 -07:00
|
|
|
#if defined(__GNUC__) || defined(__clang__)
|
|
|
|
#pragma GCC diagnostic push
|
|
|
|
#pragma GCC diagnostic ignored "-Wconversion"
|
|
|
|
#endif
|
|
|
|
#if defined(_MSC_VER) && !defined(__clang__)
|
|
|
|
#pragma warning(push)
|
|
|
|
// '=': conversion from 'crypto_word_t' to 'uint8_t', possible loss of data
|
|
|
|
#pragma warning(disable: 4242)
|
|
|
|
// 'initializing': conversion from 'crypto_word_t' to 'uint8_t', ...
|
|
|
|
#pragma warning(disable: 4244)
|
|
|
|
#endif
|
|
|
|
|
2023-09-28 18:11:05 -07:00
|
|
|
// crypto_word_t is the type that most constant-time functions use. Ideally we
|
2017-08-18 14:06:02 -04:00
|
|
|
// would like it to be |size_t|, but NaCl builds in 64-bit mode with 32-bit
|
2023-09-28 18:11:05 -07:00
|
|
|
// pointers, which means that |size_t| can be 32 bits when |BN_ULONG| is 64
|
|
|
|
// bits. Since we want to be able to do constant-time operations on a
|
|
|
|
// |BN_ULONG|, |crypto_word_t| is defined as an unsigned value with the native
|
|
|
|
// word length.
|
2017-04-20 13:51:11 -07:00
|
|
|
#if defined(OPENSSL_64_BIT)
|
2023-09-28 18:11:05 -07:00
|
|
|
typedef uint64_t crypto_word_t;
|
2018-05-18 12:45:27 -10:00
|
|
|
#define CRYPTO_WORD_BITS (64u)
|
2017-04-20 13:51:11 -07:00
|
|
|
#elif defined(OPENSSL_32_BIT)
|
2023-09-28 18:11:05 -07:00
|
|
|
typedef uint32_t crypto_word_t;
|
2018-05-18 12:45:27 -10:00
|
|
|
#define CRYPTO_WORD_BITS (32u)
|
2017-04-20 13:51:11 -07:00
|
|
|
#else
|
|
|
|
#error "Must define either OPENSSL_32_BIT or OPENSSL_64_BIT"
|
|
|
|
#endif
|
|
|
|
|
2023-09-28 18:11:05 -07:00
|
|
|
#define CONSTTIME_TRUE_W ~((crypto_word_t)0)
|
|
|
|
#define CONSTTIME_FALSE_W ((crypto_word_t)0)
|
2017-03-16 11:38:18 -04:00
|
|
|
|
2019-06-17 20:26:24 +00:00
|
|
|
// value_barrier_w returns |a|, but prevents GCC and Clang from reasoning about
|
|
|
|
// the returned value. This is used to mitigate compilers undoing constant-time
|
|
|
|
// code, until we can express our requirements directly in the language.
|
|
|
|
//
|
|
|
|
// Note the compiler is aware that |value_barrier_w| has no side effects and
|
|
|
|
// always has the same output for a given input. This allows it to eliminate
|
|
|
|
// dead code, move computations across loops, and vectorize.
|
2023-09-28 18:11:05 -07:00
|
|
|
static inline crypto_word_t value_barrier_w(crypto_word_t a) {
|
2023-02-01 23:40:18 -05:00
|
|
|
#if defined(__GNUC__) || defined(__clang__)
|
2019-06-17 20:26:24 +00:00
|
|
|
__asm__("" : "+r"(a) : /* no inputs */);
|
|
|
|
#endif
|
|
|
|
return a;
|
|
|
|
}
|
|
|
|
|
2023-05-24 16:23:59 +00:00
|
|
|
// |value_barrier_u8| could be defined as above, but compilers other than
|
|
|
|
// clang seem to still materialize 0x00..00MM instead of reusing 0x??..??MM.
|
|
|
|
|
2017-08-18 14:06:02 -04:00
|
|
|
// constant_time_msb_w returns the given value with the MSB copied to all the
|
|
|
|
// other bits.
|
2023-09-28 18:11:05 -07:00
|
|
|
static inline crypto_word_t constant_time_msb_w(crypto_word_t a) {
|
2017-03-16 11:38:18 -04:00
|
|
|
return 0u - (a >> (sizeof(a) * 8 - 1));
|
2016-06-30 08:41:28 -10:00
|
|
|
}
|
|
|
|
|
2017-08-18 14:06:02 -04:00
|
|
|
// constant_time_is_zero returns 0xff..f if a == 0 and 0 otherwise.
|
2023-09-28 18:11:05 -07:00
|
|
|
static inline crypto_word_t constant_time_is_zero_w(crypto_word_t a) {
|
2017-08-18 14:06:02 -04:00
|
|
|
// Here is an SMT-LIB verification of this formula:
|
|
|
|
//
|
|
|
|
// (define-fun is_zero ((a (_ BitVec 32))) (_ BitVec 32)
|
|
|
|
// (bvand (bvnot a) (bvsub a #x00000001))
|
|
|
|
// )
|
|
|
|
//
|
|
|
|
// (declare-fun a () (_ BitVec 32))
|
|
|
|
//
|
|
|
|
// (assert (not (= (= #x00000001 (bvlshr (is_zero a) #x0000001f)) (= a #x00000000))))
|
|
|
|
// (check-sat)
|
|
|
|
// (get-model)
|
2017-04-20 13:51:11 -07:00
|
|
|
return constant_time_msb_w(~a & (a - 1));
|
2014-11-03 18:51:20 -08:00
|
|
|
}
|
|
|
|
|
2023-09-28 18:11:05 -07:00
|
|
|
static inline crypto_word_t constant_time_is_nonzero_w(crypto_word_t a) {
|
2018-04-26 16:49:26 -10:00
|
|
|
return ~constant_time_is_zero_w(a);
|
2016-07-07 10:34:14 -10:00
|
|
|
}
|
|
|
|
|
2017-08-18 14:06:02 -04:00
|
|
|
// constant_time_eq_w returns 0xff..f if a == b and 0 otherwise.
|
2023-09-28 18:11:05 -07:00
|
|
|
static inline crypto_word_t constant_time_eq_w(crypto_word_t a,
|
|
|
|
crypto_word_t b) {
|
2017-04-20 13:51:11 -07:00
|
|
|
return constant_time_is_zero_w(a ^ b);
|
2016-06-30 08:41:28 -10:00
|
|
|
}
|
|
|
|
|
2017-08-18 14:06:02 -04:00
|
|
|
// constant_time_select_w returns (mask & a) | (~mask & b). When |mask| is all
|
|
|
|
// 1s or all 0s (as returned by the methods above), the select methods return
|
|
|
|
// either |a| (if |mask| is nonzero) or |b| (if |mask| is zero).
|
2023-09-28 18:11:05 -07:00
|
|
|
static inline crypto_word_t constant_time_select_w(crypto_word_t mask,
|
|
|
|
crypto_word_t a,
|
|
|
|
crypto_word_t b) {
|
2019-06-17 20:26:24 +00:00
|
|
|
// Clang recognizes this pattern as a select. While it usually transforms it
|
|
|
|
// to a cmov, it sometimes further transforms it into a branch, which we do
|
|
|
|
// not want.
|
|
|
|
//
|
2023-05-24 16:23:59 +00:00
|
|
|
// Hiding the value of the mask from the compiler evades this transformation.
|
|
|
|
mask = value_barrier_w(mask);
|
|
|
|
return (mask & a) | (~mask & b);
|
2016-06-30 08:41:28 -10:00
|
|
|
}
|
|
|
|
|
2023-10-02 18:05:15 -07:00
|
|
|
// constant_time_select_8 acts like |constant_time_select| but operates on
|
|
|
|
// 8-bit values.
|
|
|
|
static inline uint8_t constant_time_select_8(crypto_word_t mask, uint8_t a,
|
|
|
|
uint8_t b) {
|
|
|
|
// |mask| is a word instead of |uint8_t| to avoid materializing 0x000..0MM
|
|
|
|
// Making both |mask| and its value barrier |uint8_t| would allow the compiler
|
|
|
|
// to materialize 0x????..?MM instead, but only clang is that clever.
|
|
|
|
// However, vectorization of bitwise operations seems to work better on
|
|
|
|
// |uint8_t| than a mix of |uint64_t| and |uint8_t|, so |m| is cast to
|
|
|
|
// |uint8_t| after the value barrier but before the bitwise operations.
|
|
|
|
uint8_t m = value_barrier_w(mask);
|
|
|
|
return (m & a) | (~m & b);
|
|
|
|
}
|
|
|
|
|
|
|
|
// constant_time_conditional_memcpy copies |n| bytes from |src| to |dst| if
|
|
|
|
// |mask| is 0xff..ff and does nothing if |mask| is 0. The |n|-byte memory
|
|
|
|
// ranges at |dst| and |src| must not overlap, as when calling |memcpy|.
|
|
|
|
static inline void constant_time_conditional_memcpy(void *dst, const void *src,
|
|
|
|
const size_t n,
|
|
|
|
const crypto_word_t mask) {
|
|
|
|
debug_assert_nonsecret(!buffers_alias(dst, n, src, n));
|
|
|
|
uint8_t *out = (uint8_t *)dst;
|
|
|
|
const uint8_t *in = (const uint8_t *)src;
|
|
|
|
for (size_t i = 0; i < n; i++) {
|
|
|
|
out[i] = constant_time_select_8(mask, in[i], out[i]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-05-24 16:23:59 +00:00
|
|
|
// constant_time_conditional_memxor xors |n| bytes from |src| to |dst| if
|
|
|
|
// |mask| is 0xff..ff and does nothing if |mask| is 0. The |n|-byte memory
|
|
|
|
// ranges at |dst| and |src| must not overlap, as when calling |memcpy|.
|
|
|
|
static inline void constant_time_conditional_memxor(void *dst, const void *src,
|
|
|
|
const size_t n,
|
|
|
|
const crypto_word_t mask) {
|
2023-09-28 18:33:16 -07:00
|
|
|
debug_assert_nonsecret(!buffers_alias(dst, n, src, n));
|
2023-09-29 17:46:43 -07:00
|
|
|
aliasing_uint8_t *out = dst;
|
|
|
|
const aliasing_uint8_t *in = src;
|
2023-05-24 16:23:59 +00:00
|
|
|
for (size_t i = 0; i < n; i++) {
|
|
|
|
out[i] ^= value_barrier_w(mask) & in[i];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-09-28 18:33:16 -07:00
|
|
|
#if defined(_MSC_VER) && !defined(__clang__)
|
|
|
|
// '=': conversion from 'int64_t' to 'int32_t', possible loss of data
|
|
|
|
#pragma warning(pop)
|
|
|
|
#endif
|
|
|
|
#if defined(__GNUC__) || defined(__clang__)
|
|
|
|
#pragma GCC diagnostic pop
|
|
|
|
#endif
|
|
|
|
|
Add start of infrastructure for checking constant-time properties.
Valgrind's checking of uninitialised memory behaves very much like a
check for constant-time code: branches and memory indexes based on
uninitialised memory trigger warnings. Therefore, if we can tell
Valgrind that some secret is “uninitialised”, it'll give us a warning if
we do something non-constant-time with it.
This was the idea behind https://github.com/agl/ctgrind. But tricks like
that are no longer needed because Valgrind now comes with support for
marking regions of memory as defined or not. Therefore we can use that
API to check constant-time code.
This CL defines |CONSTTIME_SECRET| and |CONSTTIME_DECLASSIFY|, which are
no-ops unless the code is built with
|BORINGSSL_CONSTANT_TIME_VALIDATION| defined, which it isn't by default.
So this CL is a no-op itself so far. But it does show that a couple of
bits of constant-time time are, in fact, constant-time—seemingly even
when compiled with optimisations, which is nice.
The annotations in the RSA code are a) probably not marking all the
secrets as secret, and b) triggers warnings that are a little
interesting:
The anti-glitch check calls |BN_mod_exp_mont| which checks that the
input is less than the modulus. Of course, it is because the input is
the RSA plaintext that we just decrypted, but the plaintext is supposed
to be secret and so branching based on its contents isn't allows by
Valgrind. The answer isn't totally clear, but I've run out of time on
this for now.
Change-Id: I1608ed0b22d201e97595fafe46127159e02d5b1b
Reviewed-on: https://boringssl-review.googlesource.com/c/33504
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2018-12-06 17:15:58 -08:00
|
|
|
#if defined(BORINGSSL_CONSTANT_TIME_VALIDATION)
|
|
|
|
|
|
|
|
// CONSTTIME_SECRET takes a pointer and a number of bytes and marks that region
|
|
|
|
// of memory as secret. Secret data is tracked as it flows to registers and
|
|
|
|
// other parts of a memory. If secret data is used as a condition for a branch,
|
|
|
|
// or as a memory index, it will trigger warnings in valgrind.
|
Clear various false positives in RSA constant-time validation
This silences a few false positives in the valgrind-based constant-time
validation.
First, there are a few precondition checks that are publicly true, but
valgrind doesn't know that. I've added a constant_time_declassify_int
function and stuck those in there, since the existing macro is mostly
suited for macros. It also adds a value barrier in production code (see
comment for why). If we more thoroughly decoupled RSA from BIGNUM, we
could probably avoid this, since a lot of comes from going through
public BIGNUM APIs.
Next, our BIGNUM strategy is such that bounds on bignums are sometimes
computed pessimally, and then clamped down later. Modular arithmetic is
trivially bounded and avoids that, but RSA CRT involves some non-modular
computations. As a result, we actually compute a few more words than
necessary in the RSA result, and then bn_resize_words down.
bn_resize_words also has a precondition check, which checks that all
discarded words are zero. They are, but valgrind does not know that.
Similarly, the BN_bn2bin_padded call at the end checks for discarded
non-zero bytes, but valgrind does not know that, because the output is
bounded by n, the discarded bytes are zero.
I've added a bn_assert_fits_in_bytes to clear this. It's an assert in
debug mode and a declassification in constant-time validation.
I suspect a different secret integer design would avoid needing this. I
think this comes from a combination of non-modular arithmetic, not
having callers pass explicit width, and tracking public widths at the
word granularity, rather than byte or bit. (Bit would actually be most
ideal.) Maybe worth a ponder sometime.
Change-Id: I1bc9443d571d2881e2d857c70be913074deac156
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56825
Commit-Queue: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
2023-02-01 12:21:56 -05:00
|
|
|
#define CONSTTIME_SECRET(ptr, len) VALGRIND_MAKE_MEM_UNDEFINED(ptr, len)
|
Add start of infrastructure for checking constant-time properties.
Valgrind's checking of uninitialised memory behaves very much like a
check for constant-time code: branches and memory indexes based on
uninitialised memory trigger warnings. Therefore, if we can tell
Valgrind that some secret is “uninitialised”, it'll give us a warning if
we do something non-constant-time with it.
This was the idea behind https://github.com/agl/ctgrind. But tricks like
that are no longer needed because Valgrind now comes with support for
marking regions of memory as defined or not. Therefore we can use that
API to check constant-time code.
This CL defines |CONSTTIME_SECRET| and |CONSTTIME_DECLASSIFY|, which are
no-ops unless the code is built with
|BORINGSSL_CONSTANT_TIME_VALIDATION| defined, which it isn't by default.
So this CL is a no-op itself so far. But it does show that a couple of
bits of constant-time time are, in fact, constant-time—seemingly even
when compiled with optimisations, which is nice.
The annotations in the RSA code are a) probably not marking all the
secrets as secret, and b) triggers warnings that are a little
interesting:
The anti-glitch check calls |BN_mod_exp_mont| which checks that the
input is less than the modulus. Of course, it is because the input is
the RSA plaintext that we just decrypted, but the plaintext is supposed
to be secret and so branching based on its contents isn't allows by
Valgrind. The answer isn't totally clear, but I've run out of time on
this for now.
Change-Id: I1608ed0b22d201e97595fafe46127159e02d5b1b
Reviewed-on: https://boringssl-review.googlesource.com/c/33504
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2018-12-06 17:15:58 -08:00
|
|
|
|
|
|
|
// CONSTTIME_DECLASSIFY takes a pointer and a number of bytes and marks that
|
|
|
|
// region of memory as public. Public data is not subject to constant-time
|
|
|
|
// rules.
|
Clear various false positives in RSA constant-time validation
This silences a few false positives in the valgrind-based constant-time
validation.
First, there are a few precondition checks that are publicly true, but
valgrind doesn't know that. I've added a constant_time_declassify_int
function and stuck those in there, since the existing macro is mostly
suited for macros. It also adds a value barrier in production code (see
comment for why). If we more thoroughly decoupled RSA from BIGNUM, we
could probably avoid this, since a lot of comes from going through
public BIGNUM APIs.
Next, our BIGNUM strategy is such that bounds on bignums are sometimes
computed pessimally, and then clamped down later. Modular arithmetic is
trivially bounded and avoids that, but RSA CRT involves some non-modular
computations. As a result, we actually compute a few more words than
necessary in the RSA result, and then bn_resize_words down.
bn_resize_words also has a precondition check, which checks that all
discarded words are zero. They are, but valgrind does not know that.
Similarly, the BN_bn2bin_padded call at the end checks for discarded
non-zero bytes, but valgrind does not know that, because the output is
bounded by n, the discarded bytes are zero.
I've added a bn_assert_fits_in_bytes to clear this. It's an assert in
debug mode and a declassification in constant-time validation.
I suspect a different secret integer design would avoid needing this. I
think this comes from a combination of non-modular arithmetic, not
having callers pass explicit width, and tracking public widths at the
word granularity, rather than byte or bit. (Bit would actually be most
ideal.) Maybe worth a ponder sometime.
Change-Id: I1bc9443d571d2881e2d857c70be913074deac156
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56825
Commit-Queue: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
2023-02-01 12:21:56 -05:00
|
|
|
#define CONSTTIME_DECLASSIFY(ptr, len) VALGRIND_MAKE_MEM_DEFINED(ptr, len)
|
Add start of infrastructure for checking constant-time properties.
Valgrind's checking of uninitialised memory behaves very much like a
check for constant-time code: branches and memory indexes based on
uninitialised memory trigger warnings. Therefore, if we can tell
Valgrind that some secret is “uninitialised”, it'll give us a warning if
we do something non-constant-time with it.
This was the idea behind https://github.com/agl/ctgrind. But tricks like
that are no longer needed because Valgrind now comes with support for
marking regions of memory as defined or not. Therefore we can use that
API to check constant-time code.
This CL defines |CONSTTIME_SECRET| and |CONSTTIME_DECLASSIFY|, which are
no-ops unless the code is built with
|BORINGSSL_CONSTANT_TIME_VALIDATION| defined, which it isn't by default.
So this CL is a no-op itself so far. But it does show that a couple of
bits of constant-time time are, in fact, constant-time—seemingly even
when compiled with optimisations, which is nice.
The annotations in the RSA code are a) probably not marking all the
secrets as secret, and b) triggers warnings that are a little
interesting:
The anti-glitch check calls |BN_mod_exp_mont| which checks that the
input is less than the modulus. Of course, it is because the input is
the RSA plaintext that we just decrypted, but the plaintext is supposed
to be secret and so branching based on its contents isn't allows by
Valgrind. The answer isn't totally clear, but I've run out of time on
this for now.
Change-Id: I1608ed0b22d201e97595fafe46127159e02d5b1b
Reviewed-on: https://boringssl-review.googlesource.com/c/33504
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2018-12-06 17:15:58 -08:00
|
|
|
|
|
|
|
#else
|
|
|
|
|
Clear various false positives in RSA constant-time validation
This silences a few false positives in the valgrind-based constant-time
validation.
First, there are a few precondition checks that are publicly true, but
valgrind doesn't know that. I've added a constant_time_declassify_int
function and stuck those in there, since the existing macro is mostly
suited for macros. It also adds a value barrier in production code (see
comment for why). If we more thoroughly decoupled RSA from BIGNUM, we
could probably avoid this, since a lot of comes from going through
public BIGNUM APIs.
Next, our BIGNUM strategy is such that bounds on bignums are sometimes
computed pessimally, and then clamped down later. Modular arithmetic is
trivially bounded and avoids that, but RSA CRT involves some non-modular
computations. As a result, we actually compute a few more words than
necessary in the RSA result, and then bn_resize_words down.
bn_resize_words also has a precondition check, which checks that all
discarded words are zero. They are, but valgrind does not know that.
Similarly, the BN_bn2bin_padded call at the end checks for discarded
non-zero bytes, but valgrind does not know that, because the output is
bounded by n, the discarded bytes are zero.
I've added a bn_assert_fits_in_bytes to clear this. It's an assert in
debug mode and a declassification in constant-time validation.
I suspect a different secret integer design would avoid needing this. I
think this comes from a combination of non-modular arithmetic, not
having callers pass explicit width, and tracking public widths at the
word granularity, rather than byte or bit. (Bit would actually be most
ideal.) Maybe worth a ponder sometime.
Change-Id: I1bc9443d571d2881e2d857c70be913074deac156
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56825
Commit-Queue: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
2023-02-01 12:21:56 -05:00
|
|
|
#define CONSTTIME_SECRET(ptr, len)
|
|
|
|
#define CONSTTIME_DECLASSIFY(ptr, len)
|
Add start of infrastructure for checking constant-time properties.
Valgrind's checking of uninitialised memory behaves very much like a
check for constant-time code: branches and memory indexes based on
uninitialised memory trigger warnings. Therefore, if we can tell
Valgrind that some secret is “uninitialised”, it'll give us a warning if
we do something non-constant-time with it.
This was the idea behind https://github.com/agl/ctgrind. But tricks like
that are no longer needed because Valgrind now comes with support for
marking regions of memory as defined or not. Therefore we can use that
API to check constant-time code.
This CL defines |CONSTTIME_SECRET| and |CONSTTIME_DECLASSIFY|, which are
no-ops unless the code is built with
|BORINGSSL_CONSTANT_TIME_VALIDATION| defined, which it isn't by default.
So this CL is a no-op itself so far. But it does show that a couple of
bits of constant-time time are, in fact, constant-time—seemingly even
when compiled with optimisations, which is nice.
The annotations in the RSA code are a) probably not marking all the
secrets as secret, and b) triggers warnings that are a little
interesting:
The anti-glitch check calls |BN_mod_exp_mont| which checks that the
input is less than the modulus. Of course, it is because the input is
the RSA plaintext that we just decrypted, but the plaintext is supposed
to be secret and so branching based on its contents isn't allows by
Valgrind. The answer isn't totally clear, but I've run out of time on
this for now.
Change-Id: I1608ed0b22d201e97595fafe46127159e02d5b1b
Reviewed-on: https://boringssl-review.googlesource.com/c/33504
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2018-12-06 17:15:58 -08:00
|
|
|
|
|
|
|
#endif // BORINGSSL_CONSTANT_TIME_VALIDATION
|
|
|
|
|
2023-09-28 18:11:05 -07:00
|
|
|
static inline crypto_word_t constant_time_declassify_w(crypto_word_t v) {
|
Clear various false positives in RSA constant-time validation
This silences a few false positives in the valgrind-based constant-time
validation.
First, there are a few precondition checks that are publicly true, but
valgrind doesn't know that. I've added a constant_time_declassify_int
function and stuck those in there, since the existing macro is mostly
suited for macros. It also adds a value barrier in production code (see
comment for why). If we more thoroughly decoupled RSA from BIGNUM, we
could probably avoid this, since a lot of comes from going through
public BIGNUM APIs.
Next, our BIGNUM strategy is such that bounds on bignums are sometimes
computed pessimally, and then clamped down later. Modular arithmetic is
trivially bounded and avoids that, but RSA CRT involves some non-modular
computations. As a result, we actually compute a few more words than
necessary in the RSA result, and then bn_resize_words down.
bn_resize_words also has a precondition check, which checks that all
discarded words are zero. They are, but valgrind does not know that.
Similarly, the BN_bn2bin_padded call at the end checks for discarded
non-zero bytes, but valgrind does not know that, because the output is
bounded by n, the discarded bytes are zero.
I've added a bn_assert_fits_in_bytes to clear this. It's an assert in
debug mode and a declassification in constant-time validation.
I suspect a different secret integer design would avoid needing this. I
think this comes from a combination of non-modular arithmetic, not
having callers pass explicit width, and tracking public widths at the
word granularity, rather than byte or bit. (Bit would actually be most
ideal.) Maybe worth a ponder sometime.
Change-Id: I1bc9443d571d2881e2d857c70be913074deac156
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56825
Commit-Queue: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
2023-02-01 12:21:56 -05:00
|
|
|
// Return |v| through a value barrier to be safe. Valgrind-based constant-time
|
|
|
|
// validation is partly to check the compiler has not undone any constant-time
|
|
|
|
// work. Any place |BORINGSSL_CONSTANT_TIME_VALIDATION| influences
|
|
|
|
// optimizations, this validation is inaccurate.
|
|
|
|
//
|
|
|
|
// However, by sending pointers through valgrind, we likely inhibit escape
|
|
|
|
// analysis. On local variables, particularly booleans, we likely
|
|
|
|
// significantly impact optimizations.
|
|
|
|
//
|
|
|
|
// Thus, to be safe, stick a value barrier, in hopes of comparably inhibiting
|
|
|
|
// compiler analysis.
|
2023-02-02 23:56:26 -05:00
|
|
|
CONSTTIME_DECLASSIFY(&v, sizeof(v));
|
|
|
|
return value_barrier_w(v);
|
|
|
|
}
|
|
|
|
|
Merge BoringSSL 9855c1c: Add a constant-time fallback GHASH
implementation.
*ring* tries to work without type-punning `memcpy`, so the use of that
in `GFp_gcm_ghash_nohw` was replaced by the use of `u64_from_be_bytes`.
This will (I hope) also help with the eventual support for big-endian
targets. Here's the diff from BoringSSL in that function:
```diff
-void gcm_ghash_nohw(uint64_t Xi[2], const u128 Htable[16], const uint8_t *inp,
- size_t len) {
+void GFp_gcm_ghash_nohw(uint64_t Xi[2], const u128 Htable[16], const uint8_t *inp,
+ size_t len) {
uint64_t swapped[2];
swapped[0] = CRYPTO_bswap8(Xi[1]);
swapped[1] = CRYPTO_bswap8(Xi[0]);
while (len >= 16) {
- uint64_t block[2];
- OPENSSL_memcpy(block, inp, 16);
- swapped[0] ^= CRYPTO_bswap8(block[1]);
- swapped[1] ^= CRYPTO_bswap8(block[0]);
+ swapped[0] ^= u64_from_be_bytes(&inp[8]);
+ swapped[1] ^= u64_from_be_bytes(inp);
gcm_polyval_nohw(swapped, &Htable[0]);
inp += 16;
len -= 16;
```
I also had to add a couple of (uint32_t) truncating casts where
BoringSSL expects an implicit truncation to occur, to avoid
`-Werror=conversion`.
During the merge, I found that `GFp_gcm_gmult_clmul` had its
`.cfi_startproc` on the wrong line. I fixed that as part of the merge.
During my review of the BoringSSL changes, I noticed that BoringSSL had
left some of the dead code in ghash-x86_64.pl, which had previously been
removed in *ring*. That removal is being done in BoringSSL in [1].
[1] https://boringssl-review.googlesource.com/c/boringssl/+/41144
2020-04-30 15:45:25 -05:00
|
|
|
// Endianness conversions.
|
2016-03-29 09:16:29 -04:00
|
|
|
|
2017-12-28 19:31:17 -08:00
|
|
|
#if defined(__GNUC__) && __GNUC__ >= 2
|
|
|
|
static inline uint32_t CRYPTO_bswap4(uint32_t x) {
|
|
|
|
return __builtin_bswap32(x);
|
|
|
|
}
|
2021-03-29 12:54:16 -04:00
|
|
|
|
|
|
|
static inline uint64_t CRYPTO_bswap8(uint64_t x) {
|
|
|
|
return __builtin_bswap64(x);
|
|
|
|
}
|
2017-12-28 19:31:17 -08:00
|
|
|
#elif defined(_MSC_VER)
|
2020-05-27 16:09:47 -05:00
|
|
|
#pragma warning(push, 3)
|
2019-01-10 13:44:42 -08:00
|
|
|
#include <stdlib.h>
|
2020-05-27 16:09:47 -05:00
|
|
|
#pragma warning(pop)
|
2017-12-28 19:31:17 -08:00
|
|
|
#pragma intrinsic(_byteswap_uint64, _byteswap_ulong)
|
|
|
|
static inline uint32_t CRYPTO_bswap4(uint32_t x) {
|
|
|
|
return _byteswap_ulong(x);
|
|
|
|
}
|
2021-03-29 12:54:16 -04:00
|
|
|
|
|
|
|
static inline uint64_t CRYPTO_bswap8(uint64_t x) {
|
|
|
|
return _byteswap_uint64(x);
|
|
|
|
}
|
2017-12-28 19:31:17 -08:00
|
|
|
#endif
|
|
|
|
|
2021-05-02 14:42:05 -07:00
|
|
|
#if !defined(RING_CORE_NOSTDLIBINC)
|
2020-11-16 22:34:29 -08:00
|
|
|
#include <string.h>
|
|
|
|
#endif
|
|
|
|
|
2021-03-29 15:44:52 -07:00
|
|
|
static inline void *OPENSSL_memcpy(void *dst, const void *src, size_t n) {
|
2021-05-02 14:42:05 -07:00
|
|
|
#if !defined(RING_CORE_NOSTDLIBINC)
|
2020-11-16 22:34:29 -08:00
|
|
|
if (n == 0) {
|
|
|
|
return dst;
|
|
|
|
}
|
|
|
|
return memcpy(dst, src, n);
|
|
|
|
#else
|
2023-09-29 17:46:43 -07:00
|
|
|
aliasing_uint8_t *d = dst;
|
|
|
|
const aliasing_uint8_t *s = src;
|
2020-11-16 22:34:29 -08:00
|
|
|
for (size_t i = 0; i < n; ++i) {
|
|
|
|
d[i] = s[i];
|
2019-06-04 11:34:14 -10:00
|
|
|
}
|
2020-11-16 22:34:29 -08:00
|
|
|
return dst;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2021-03-29 15:44:52 -07:00
|
|
|
static inline void *OPENSSL_memset(void *dst, int c, size_t n) {
|
2021-05-02 14:42:05 -07:00
|
|
|
#if !defined(RING_CORE_NOSTDLIBINC)
|
2020-11-16 22:34:29 -08:00
|
|
|
if (n == 0) {
|
|
|
|
return dst;
|
|
|
|
}
|
|
|
|
return memset(dst, c, n);
|
|
|
|
#else
|
2023-09-29 17:46:43 -07:00
|
|
|
aliasing_uint8_t *d = dst;
|
2020-11-16 22:34:29 -08:00
|
|
|
for (size_t i = 0; i < n; ++i) {
|
2023-09-29 17:46:43 -07:00
|
|
|
d[i] = (aliasing_uint8_t)c;
|
2020-11-16 22:34:29 -08:00
|
|
|
}
|
|
|
|
return dst;
|
|
|
|
#endif
|
2019-06-04 11:34:14 -10:00
|
|
|
}
|
|
|
|
|
Extract common rotl/rotr functions.
We have a ton of per-file rotation functions, often with generic names
that do not tell you whether they are uint32_t vs uint64_t, or rotl vs
rotr.
Additionally, (x >> r) | (x << (32 - r)) is UB at r = 0.
(x >> r) | (x << ((-r) & 31)) works for 0 <= r < 32, which is what
cast.c does. GCC and Clang recognize this pattern as a rotate, but MSVC
doesn't. MSVC does, however, provide functions for this.
We usually rotate by a non-zero constant, which makes this moot, but
rotation comes up often enough that it's worth extracting out. Some
particular changes to call out:
- I've switched sha256.c from rotl to rotr. There was a comment
explaining why it differed from the specification. Now that we have
both functions, it's simpler to just match the specification.
- I've dropped all the inline assembly from sha512.c. Compilers should
be able to recognize rotations in 2021.
Change-Id: Ia1030e8bfe94dad92514ed1c28777447c48b82f9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49765
Reviewed-by: Adam Langley <agl@google.com>
2021-10-03 01:53:38 -04:00
|
|
|
|
2021-03-29 12:54:16 -04:00
|
|
|
// Loads and stores.
|
|
|
|
//
|
|
|
|
// The following functions load and store sized integers with the specified
|
|
|
|
// endianness. They use |memcpy|, and so avoid alignment or strict aliasing
|
|
|
|
// requirements on the input and output pointers.
|
|
|
|
|
2022-11-10 14:23:38 +01:00
|
|
|
#if defined(__BYTE_ORDER__) && defined(__ORDER_BIG_ENDIAN__)
|
|
|
|
#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
|
|
|
|
#define RING_BIG_ENDIAN
|
|
|
|
#endif
|
|
|
|
#endif
|
|
|
|
|
2021-03-29 12:54:16 -04:00
|
|
|
static inline uint32_t CRYPTO_load_u32_le(const void *in) {
|
|
|
|
uint32_t v;
|
|
|
|
OPENSSL_memcpy(&v, in, sizeof(v));
|
2022-11-10 14:23:38 +01:00
|
|
|
#if defined(RING_BIG_ENDIAN)
|
|
|
|
return CRYPTO_bswap4(v);
|
|
|
|
#else
|
2021-03-29 12:54:16 -04:00
|
|
|
return v;
|
2022-11-10 14:23:38 +01:00
|
|
|
#endif
|
2021-03-29 12:54:16 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void CRYPTO_store_u32_le(void *out, uint32_t v) {
|
2022-11-10 14:23:38 +01:00
|
|
|
#if defined(RING_BIG_ENDIAN)
|
|
|
|
v = CRYPTO_bswap4(v);
|
|
|
|
#endif
|
2021-03-29 12:54:16 -04:00
|
|
|
OPENSSL_memcpy(out, &v, sizeof(v));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint32_t CRYPTO_load_u32_be(const void *in) {
|
|
|
|
uint32_t v;
|
|
|
|
OPENSSL_memcpy(&v, in, sizeof(v));
|
2022-11-10 14:23:38 +01:00
|
|
|
#if !defined(RING_BIG_ENDIAN)
|
2021-03-29 12:54:16 -04:00
|
|
|
return CRYPTO_bswap4(v);
|
2022-11-10 14:23:38 +01:00
|
|
|
#else
|
|
|
|
return v;
|
|
|
|
#endif
|
2021-03-29 12:54:16 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void CRYPTO_store_u32_be(void *out, uint32_t v) {
|
2022-11-10 14:23:38 +01:00
|
|
|
#if !defined(RING_BIG_ENDIAN)
|
2021-03-29 12:54:16 -04:00
|
|
|
v = CRYPTO_bswap4(v);
|
2022-11-10 14:23:38 +01:00
|
|
|
#endif
|
2021-03-29 12:54:16 -04:00
|
|
|
OPENSSL_memcpy(out, &v, sizeof(v));
|
|
|
|
}
|
|
|
|
|
2022-05-13 17:06:56 -04:00
|
|
|
static inline uint64_t CRYPTO_load_u64_le(const void *in) {
|
|
|
|
uint64_t v;
|
|
|
|
OPENSSL_memcpy(&v, in, sizeof(v));
|
2022-11-10 14:23:38 +01:00
|
|
|
#if defined(RING_BIG_ENDIAN)
|
|
|
|
return CRYPTO_bswap8(v);
|
|
|
|
#else
|
2022-05-13 17:06:56 -04:00
|
|
|
return v;
|
2022-11-10 14:23:38 +01:00
|
|
|
#endif
|
2022-05-13 17:06:56 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void CRYPTO_store_u64_le(void *out, uint64_t v) {
|
2022-11-10 14:23:38 +01:00
|
|
|
#if defined(RING_BIG_ENDIAN)
|
|
|
|
v = CRYPTO_bswap8(v);
|
|
|
|
#endif
|
2022-05-13 17:06:56 -04:00
|
|
|
OPENSSL_memcpy(out, &v, sizeof(v));
|
|
|
|
}
|
|
|
|
|
2021-03-29 12:54:16 -04:00
|
|
|
static inline uint64_t CRYPTO_load_u64_be(const void *ptr) {
|
|
|
|
uint64_t ret;
|
|
|
|
OPENSSL_memcpy(&ret, ptr, sizeof(ret));
|
2022-11-10 14:23:38 +01:00
|
|
|
#if !defined(RING_BIG_ENDIAN)
|
2021-03-29 12:54:16 -04:00
|
|
|
return CRYPTO_bswap8(ret);
|
2022-11-10 14:23:38 +01:00
|
|
|
#else
|
|
|
|
return ret;
|
|
|
|
#endif
|
2021-03-29 12:54:16 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void CRYPTO_store_u64_be(void *out, uint64_t v) {
|
2022-11-10 14:23:38 +01:00
|
|
|
#if !defined(RING_BIG_ENDIAN)
|
2021-03-29 12:54:16 -04:00
|
|
|
v = CRYPTO_bswap8(v);
|
2022-11-10 14:23:38 +01:00
|
|
|
#endif
|
2021-03-29 12:54:16 -04:00
|
|
|
OPENSSL_memcpy(out, &v, sizeof(v));
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-12-23 03:42:39 -05:00
|
|
|
// Runtime CPU feature support
|
|
|
|
|
|
|
|
#if defined(OPENSSL_X86) || defined(OPENSSL_X86_64)
|
|
|
|
// OPENSSL_ia32cap_P contains the Intel CPUID bits when running on an x86 or
|
|
|
|
// x86-64 system.
|
|
|
|
//
|
|
|
|
// Index 0:
|
|
|
|
// EDX for CPUID where EAX = 1
|
|
|
|
// Bit 20 is always zero
|
|
|
|
// Bit 28 is adjusted to reflect whether the data cache is shared between
|
|
|
|
// multiple logical cores
|
|
|
|
// Bit 30 is used to indicate an Intel CPU
|
|
|
|
// Index 1:
|
|
|
|
// ECX for CPUID where EAX = 1
|
|
|
|
// Bit 11 is used to indicate AMD XOP support, not SDBG
|
|
|
|
// Index 2:
|
|
|
|
// EBX for CPUID where EAX = 7
|
|
|
|
// Index 3:
|
|
|
|
// ECX for CPUID where EAX = 7
|
|
|
|
//
|
|
|
|
// Note: the CPUID bits are pre-adjusted for the OSXSAVE bit and the YMM and XMM
|
|
|
|
// bits in XCR0, so it is not necessary to check those.
|
|
|
|
extern uint32_t OPENSSL_ia32cap_P[4];
|
2014-06-20 12:00:00 -07:00
|
|
|
#endif
|
|
|
|
|
2017-08-18 14:06:02 -04:00
|
|
|
#endif // OPENSSL_HEADER_CRYPTO_INTERNAL_H
|