Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17528)
The `func` parameter was incorrect. It was documented as `const char *func`
instead of `const char **func`.
CLA: trivial
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17522)
These compilers define _ARCH_PPC64 for 32 bit builds
so we cannot depend solely on this define to identify
32 bit build.
Fixes#17087
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17497)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17499)
During counting of the unprocessed records, return code is treated in a
wrong way. This forces kTLS RX path to be skipped in case of presence
of unprocessed records.
CLA: trivial
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17492)
This takes out the lock step stacks that allow a fast property to name
resolution. Follow on from #17325.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17388)
Also update and slightly extend the respective documentation and simplify some code.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16251)
SM3 hardware instruction is optional feature of crypto extension for
aarch64. This implementation accelerates SM3 via SM3 instructions. For
the platform not supporting SM3 instruction, the original C
implementation still works. Thanks to AliBaba for testing and reporting
the following perf numbers for Yitian710:
Benchmark on T-Head Yitian-710 2.75GHz:
Before:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
sm3 49297.82k 121062.63k 223106.05k 283371.52k 307574.10k 309400.92k
After (33% - 74% faster):
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
sm3 65640.01k 179121.79k 359854.59k 481448.96k 534055.59k 538274.47k
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17454)
EVP_MD_CTX_FLAG_NON_FIPS_ALLOW macro is obsolete and unused from
openssl-3.0 onwards
CLA: trivial
Signed-off-by: Shreenidhi Shedi <sshedi@vmware.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17484)
Add null checks to avoid dereferencing a pointer that could be null.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/17488)
PR #17255 fixed a bug in EVP_DigestInit_ex(). While backporting the PR
to 1.1.1 (see #17472) I spotted an error in the original patch. This fixes
it.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17473)
Not all platforms support tsan operations, those that don't need to have an
alternative locking path.
Fixes#17447
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/17479)
Most of the DRGB code is run under lock from the EVP layer. This is relied
on to make the majority of TSAN operations safe. However, it is still necessary
to enable locking for all DRBGs created.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/17479)
Doing the tsan operations under lock would be difficult to arrange here (locks
require memory allocation).
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/17479)
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17471)
Specifically:
* out of range
* unsigned negatives
* inexact reals
* bad param types
* buffers that are too small
* null function arguments
* unknown sizes of real
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17440)
Although we had a test for fetching an encoder/decoder/store loader it
did not use a query string. The issue highlighted by #17456 only occurs
if a query string is used.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17459)
Attempting to fetch one of the above and providing a query string was
failing with an internal assertion error. We must ensure that we give the
provider when calling ossl_method_store_cache_set()
Fixes#17456
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17459)
OSSL_PARAMs that are of type OSSL_PARAM_INTEGER or
OSSL_PARAM_UNSIGNED_INTEGER can be obtained using any of the functions
EVP_PKEY_get_int_param(), EVP_PKEY_get_size_t_param() or
EVP_PKEY_get_bn_param(). The former two will fail if the parameter is too
large to fit into the C variable. We clarify this in the documentation.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17445)
We already statically link libcrypto to endecode_test even in a "shared"
build. This can cause problems on some platforms with tests that load the
legacy provider which is dynamically linked to libcrypto. Two versions of
libcrypto are then linked to the same executable which can lead to crashes.
Fixes#17059
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17345)
We check that the init and cleanup functions for the custom method are
called as expected.
Based on an original reproducer by Dmitry Belyavsky from issue #17149.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/17255)
If an EVP_MD_CTX is reused then memory allocated and stored in md_data
can be leaked unless the EVP_MD's cleanup function is called.
Fixes#17149
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/17255)
MDs created via EVP_MD_meth_new() are inherently legacy and therefore
need to go down the legacy route when they are used.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/17255)
When compiling openssl for tianocore compiling abs_val() and pow_10()
fails with the following error because SSE support is disabled:
crypto/bio/bio_print.c:587:46: error: SSE register return with SSE disabled
Fix that by using EFIAPI calling convention when compiling for UEFI.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17442)
GCC's __ARMEL__ and __ARMEB__ defines denote little- and big-endian arm,
respectively. They are not defined on aarch64, which instead use
__AARCH64EL__ and __AARCH64EB__.
However, OpenSSL's assembly originally used the 32-bit defines on both
platforms and even define __ARMEL__ and __ARMEB__ in arm_arch.h. This is
less portable and can even interfere with other headers, which use
__ARMEL__ to detect little-endian arm.
Over time, the aarch64 assembly has switched to the correct defines,
such as in 32bbb62ea6. This commit
finishes the job: poly1305-armv8.pl needed a fix and the dual-arch
armx.pl files get one more transform to convert from 32-bit to 64-bit.
(There is an even more official endianness detector, __ARM_BIG_ENDIAN in
the Arm C Language Extensions. But I've stuck with the GCC ones here as
that would be a larger change.)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/17373)
