For some reason, the code here was made to got through the provider
specific init functions. This is very very dangerous if the provider
specific functions were to change in any way (such as changes to the
implementation context structure).
Instead, use the init functions from the base blake2 implementations
directly.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22079)
The size of the datagram header is significantly larger that we might
expect on NonStop (probably driven by sizeof(BIO_ADDR)). We adjust the
size of the default buffer to take into account the header size and the
mtu.
Fixes#22013
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22058)
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22063)
That seems to be only an issue for RSA-PSS with parameters.
Spotted by code review, so it looks like there is no test coverage for this.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22032)
void f() should probably be void f(void)
Found by running the checkpatch.pl Linux script to enforce coding style.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21468)
Found by running the checkpatch.pl Linux script to enforce coding style.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21468)
Found by running the checkpatch.pl Linux script to enforce coding style.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21468)
Some old glibc versions have recvmmsg but not sendmmsg. We require both to
use that functionality. Introduce a test to check we have a sufficiently
recent version of glibc.
Fixes#22021
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/22036)
This assembly implementation for ChaCha20 includes three code paths:
scalar path, 128-bit LSX path and 256-bit LASX path. We prefer the
LASX path or LSX path if the hardware and system support these
extensions.
There are 32 vector registers avaialable in the LSX and LASX
extensions. So, we can load the 16 initial states and the 16
intermediate states of ChaCha into the 32 vector registers for
calculating in the implementation. The test results on the 3A5000
and 3A6000 show that this assembly implementation significantly
improves the performance of ChaCha20 on LoongArch based machines.
The detailed test results are as following.
Test with:
$ openssl speed -evp chacha20
3A5000
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
C code 178484.53k 282789.93k 311793.70k 322234.99k 324405.93k 324659.88k
assembly code 223152.28k 407863.65k 989520.55k 2049192.96k 2127248.70k 2131749.55k
+25% +44% +217% +536% +556% +557%
3A6000
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
C code 214945.33k 310041.75k 340724.22k 349949.27k 352925.01k 353140.74k
assembly code 299151.34k 492766.34k 2070166.02k 4300909.91k 4473978.88k 4499084.63k
+39% +59% +508% +1129% +1168% +1174%
Signed-off-by: Min Zhou <zhoumin@loongson.cn>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21998)
In the error handling case the memory in
vb->users_pwd was accidentally not released.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21981)
When the provider's load function returned with an error, the libcrypto
error flag was only set if EOF hadn't been reached. This is troublesome,
as an error can very well occur during the last load before EOF is reached!
Also, the error flag was never reset, even though documentation specifies
that it should indicate an error in the last load (i.e. not the one before
that).
Fixes#21968
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21976)
There is a rarely used feature that can be enabled
with `./config enable-crypto-mdebug` when additionally
the environment variable OPENSSL_MALLOC_FAILURES is used.
It turns out to be possible that CRYPTO_zalloc may
create a leak when the memory is allocated and then
the shouldfail happens, then the memory is lost.
Likewise when OPENSSL_realloc is used with size=0,
then the memory is to be free'd but here the shouldfail
check is too early, and the failure may prevent the
memory to be freed thus creating a bogus memory leak.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21944)
The PKCS5 (RFC 8018) standard uses a 64 bit salt length for PBE, and
recommends a minimum of 64 bits for PBES2. For FIPS compliance PBKDF2
requires a salt length of 128 bits.
This affects OpenSSL command line applications such as "genrsa" and "pkcs8"
and API's such as PEM_write_bio_PrivateKey() that are reliant on the
default salt length.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21858)
clang-cl.exe defines __clang__ and _MSC_VER but not __GNUC__, so a clang-
specific guard is needed to get the correct ALIGNxx versions.
Fixes#21914
Change-Id: Icdc047b182ad1ba61c7b1b06a1e951eda1a0c33d
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21921)
This affects some Poly1305 assembler functions
which are only used for certain CPU types.
Remove those functions for Windows targets,
as a simple interim solution.
Fixes#21522
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21808)
This code was added in error and is entirely redundant. It is also an
expensive operation (e.g. see #21833).
Fixes#21834
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21902)
Assembly acceleration secp384r1 opts to not use any callee-save VSRs, as
VSX enabled systems make extensive use of renaming, and so writebacks in
felem_{mul,square}() can be reordered for best cache effects.
Remove stack allocations. This in turn fixes unmatched push/pops in
felem_{mul,square}().
Signed-off-by: Rohan McLure <rohan.mclure@linux.ibm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21749)
OPENSSL_init_crypto() with OPENSSL_INIT_LOAD_CONFIG must load the configuration
into the initial global default library context, not the currently set default
library context.
OPENSSL_init_crypto() with OPENSSL_INIT_LOAD_CONFIG may be called within other
OpenSSL API functions, e.g. from within EVP_PKEY_CTX_new_xxx() when initializing
a pkey context, to perform implicit initialization, if it has not been
initialized yet. This implicit initialization may happen at a time when an
application has already create its own library context and made it the default
library context. So loading the config into the current default library context
would load it into the applications library context.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21897)
Popping the $output argument is more robust and it also needs to be
placed in double quotes to handle spaces in paths.
Fixes#21874Fixes#21876
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/21877)
The assembler will complain when we include loongarch_arch.h in
an assembly file as following:
crypto/loongarch_arch.h: Assembler messages:
crypto/loongarch_arch.h:12: Fatal error: no match insn: extern unsigned int OPENSSL_loongarch_hwcap_P
So, the sentence of `extern unsigned int OPENSSL_loongarch_hwcap_P`
should be guarded with "#ifndef __ASSEMBLER__".
Fixes#21838.
Signed-off-by: Min Zhou <zhoumin@loongson.cn>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21839)
This is used to calculate the TSA's public key certificate identifier.
The default algorithm is changed from sha1 to sha256.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21794)
Treat keys with EVP_PKEY_RSA_PSS the same as EVP_PKEY_RSA in EVP_PKEY_can_sign()
and detect_foreign_key() which is called by EVP_PKEY_assign().
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21819)
The get_rsa_payload_x() functions should also allow to get the payload
for RSA-PSS keys.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21818)
Controls 'rsa_keygen_pubexp' and 'rsa_keygen_primes' should also be allowed
for RSA-PSS keys.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21818)
This improves tracking where the failure was triggered.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21700)
Make sure we free the stack of names we allocated in an error path.
Found by the reproducible error patch in #21668
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/21796)
This really cannot be ever called with NULL store_ctx
and the check confuses Coverity.
Fixes Coverity 1538865
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21755)
This change is for feature request #21679.
Adds a couple of setters to aid with custom CRL validation.
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21737)
Make sure we free process_data_dest if it is not actually used.
Found by the reproducible error patch in #21668
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21741)
issue: https://github.com/openssl/openssl/issues/21718
build break reported:
crypto/threads_pthread.c:76:5: warning: implicit declaration of function 'pthread_mutexattr_settype'; did you mean 'pthread_mutexattr_destroy'? [-Wimplicit-function-declaration]
76 | pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
| pthread_mutexattr_destroy
crypto/threads_pthread.c:76:38: error: 'PTHREAD_MUTEX_NORMAL' undeclared (first use in this function); did you mean 'PTHREAD_MUTEX_TIMED_NP'?
76 | pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL);
| ^~~~~~~~~~~~~~~~~~~~
| PTHREAD_MUTEX_TIMED_NP
This occurs because PTHREAD_MUTEX_NORMAL is only defined in glibc if
__USE_UNIX98 or __USE_XOPEN2K8 is defined, which is derived from setting
__USE_POSIX_C_SOURCE or __XOPEN_SOURCE is selected in the glibc feature
set for a build. Since openssl selects no specific feature set from
glibc, the build break occurs
We could select a feature set of course, but that seems like a
significant discussion to have prior to doing so. Instead, the simpler
solution is to just not set the mutex type at all, given that
pthread_mutexattr_init sets the default mutex type, which should be akin
to normal anyway (i.e. no mutex error checking or allowed-recursive
behavior)
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21726)
Fixes#21198
decoder objects were setting propq as NULL.
Added a set_ctx/settable_ctx to all decoders that should supply
a property query parameter to internal functions.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21219)
Found via the reproducible error injection in #21668
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/21723)
The routines declared in there are entirely libcrypto internal, so
include/crypto/decoder.h is better suited for them.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/21733)
bn_wexpand can fail as the result of a memory allocation failure. We
should not be calling ossl_assert() on its result because it can fail in
normal operation.
Found via the reproducible error injection in #21668
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/21725)
A recursive OPENSSL_init_crypto(OPENSSL_INIT_LOAD_CRYPTO_STRINGS) call
may happen if an out-of-memory error happens at the first callstack,
and the dead-lock happens at the second callstack, because ossl_err_get_state_int
calls OPENSSL_init_crypto(OPENSSL_INIT_LOAD_CRYPTO_STRINGS) although that
call is currently already executing.
At least on posix system this causes the process to freeze at this
point, and must be avoided whatever it takes.
The fix is using err_shelve_state around the critical region, which
makes ossl_err_get_state_int return early and not call the recursive
OPENSSL_init_crypto(OPENSSL_INIT_LOAD_CRYPTO_STRINGS).
This can be reproduced with my error injection patch.
The test vector has been validated on the master branch:
$ ERROR_INJECT=1692279870 ../util/shlib_wrap.sh ./asn1parse-test ./corpora/asn1parse/027f6e82ba01d9db9a9167b83e56cc9f2c602550
ERROR_INJECT=1692279870
#0 0x7f280b42fef8 in __sanitizer_print_stack_trace ../../../../src/libsanitizer/asan/asan_stack.cpp:86
#1 0x5610a3f396b4 in my_malloc fuzz/test-corpus.c:114
#2 0x7f280a2eb94c in CRYPTO_malloc crypto/mem.c:177
#3 0x7f280a2dafdb in OPENSSL_LH_insert crypto/lhash/lhash.c:114
#4 0x7f280a1c87fe in err_load_strings crypto/err/err.c:264
#5 0x7f280a1c87fe in err_load_strings crypto/err/err.c:259
#6 0x7f280a1c87fe in ERR_load_strings_const crypto/err/err.c:301
#7 0x7f280a6f513b in ossl_err_load_PROV_strings providers/common/provider_err.c:233
#8 0x7f280a1cf015 in ossl_err_load_crypto_strings crypto/err/err_all.c:109
#9 0x7f280a2e9b8c in ossl_init_load_crypto_strings crypto/init.c:190
#10 0x7f280a2e9b8c in ossl_init_load_crypto_strings_ossl_ crypto/init.c:181
#11 0x7f2808cfbf67 (/lib/x86_64-linux-gnu/libc.so.6+0x99f67)
#12 0x7f280a32301e in CRYPTO_THREAD_run_once crypto/threads_pthread.c:154
#13 0x7f280a2ea1da in OPENSSL_init_crypto crypto/init.c:553
#14 0x5610a3f38e2f in FuzzerInitialize fuzz/asn1parse.c:29
#15 0x5610a3f38783 in main fuzz/test-corpus.c:194
#16 0x7f2808c8bd8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f)
#17 0x7f2808c8be3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f)
#18 0x5610a3f38d34 in _start (/home/runner/work/openssl/openssl/fuzz/asn1parse-test+0x3d34)
AddressSanitizer:DEADLYSIGNAL
=================================================================
==27629==ERROR: AddressSanitizer: ABRT on unknown address 0x03e900006e23 (pc 0x7f2808cfbef8 bp 0x7f280b36afe0 sp 0x7ffd545b2460 T0)
#0 0x7f2808cfbef8 (/lib/x86_64-linux-gnu/libc.so.6+0x99ef8)
#1 0x7f280a32301e in CRYPTO_THREAD_run_once crypto/threads_pthread.c:154
#2 0x7f280a2ea1da in OPENSSL_init_crypto crypto/init.c:553
#3 0x7f280a1c935e in ossl_err_get_state_int crypto/err/err.c:705
#4 0x7f280a1cf1f9 in ERR_new crypto/err/err_blocks.c:20
#5 0x7f280a2eb9ac in CRYPTO_malloc crypto/mem.c:205
#6 0x7f280a2dafdb in OPENSSL_LH_insert crypto/lhash/lhash.c:114
#7 0x7f280a1c87fe in err_load_strings crypto/err/err.c:264
#8 0x7f280a1c87fe in err_load_strings crypto/err/err.c:259
#9 0x7f280a1c87fe in ERR_load_strings_const crypto/err/err.c:301
#10 0x7f280a6f513b in ossl_err_load_PROV_strings providers/common/provider_err.c:233
#11 0x7f280a1cf015 in ossl_err_load_crypto_strings crypto/err/err_all.c:109
#12 0x7f280a2e9b8c in ossl_init_load_crypto_strings crypto/init.c:190
#13 0x7f280a2e9b8c in ossl_init_load_crypto_strings_ossl_ crypto/init.c:181
#14 0x7f2808cfbf67 (/lib/x86_64-linux-gnu/libc.so.6+0x99f67)
#15 0x7f280a32301e in CRYPTO_THREAD_run_once crypto/threads_pthread.c:154
#16 0x7f280a2ea1da in OPENSSL_init_crypto crypto/init.c:553
#17 0x5610a3f38e2f in FuzzerInitialize fuzz/asn1parse.c:29
#18 0x5610a3f38783 in main fuzz/test-corpus.c:194
#19 0x7f2808c8bd8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f)
#20 0x7f2808c8be3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f)
#21 0x5610a3f38d34 in _start (/home/runner/work/openssl/openssl/fuzz/asn1parse-test+0x3d34)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: ABRT (/lib/x86_64-linux-gnu/libc.so.6+0x99ef8)
==27629==ABORTING
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/21683)
CLA: trivial
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21692)
This happens if this function is called for signed content.
Added ossl_cms_env_enc_content_free() for cleaning enveloped content.
Fixed indentation in ossl_cms_env_enc_content_free
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21676)
This fixes the reported crashes 32-bit HPUX systems due to
raw out and inp pointer values, and adds one nop instruction
on 64-bit systems, like it is done in other assembly modules
for those systems.
The fix was tested by @johnkohl-hcl see:
https://github.com/openssl/openssl/issues/17067#issuecomment-1668468033Fixes#17067
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21681)
When $label == "0", $label is not truthy, so `if ($label)` thinks there isn't
a label. Correct this by looking at the result of the s/// command.
Verified that there are no changes in the .S files created during a normal
build, and that the "0:" labels appear in the translation given in the error
report (and they are the only difference in the before and after output).
Fixes#21647
Change-Id: I5f2440100c62360bf4bdb7c7ece8dddd32553c79
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21653)
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21587)
Co-authored-by: suikammd <suikalala@gmail.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21298)
Add an assembly implementation of felem_{square,mul}, which will be
implemented whenever Altivec support is present and the core implements
ISA 3.0 (Power 9) or greater.
Signed-off-by: Rohan McLure <rohanmclure@linux.ibm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21471)
Adopt a 56-bit redundant-limb Solinas' reduction approach for efficient
modular multiplication in P384. This has the affect of accelerating
digital signing by 446% and verification by 106%. The implementation
strategy and names of methods are the same as that provided in
ecp_nistp224 and ecp_nistp521.
As in Commit 1036749883 ("ec: Add run time code selection for p521
field operations"), allow for run time selection of implementation for
felem_{square,mul}, where an assembly implementation is proclaimed to
be present when ECP_NISTP384_ASM is present.
Signed-off-by: Rohan McLure <rohanmclure@linux.ibm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21471)
Runtime selection of implementations for felem_{square,mul} depends on
felem_{square,mul}_wrapper functions, which overwrite function points in
a similar design to that of .plt.got sections used by program loaders
during dynamic linking.
There's no reason why these functions need to have external linkage.
Mark static.
Signed-off-by: Rohan McLure <rohanmclure@linux.ibm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21471)
When decoding 0 as the selection means to decode anything
you get.
However when exporting and then importing the key data 0 as
selection is not meaningful.
So we set it to OSSL_KEYMGMT_SELECT_ALL to make the export/import
function export/import everything that we have decoded.
Fixes#21493
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21519)
Reviewed-by: Paul Dale <pauli@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/21579)
The PEM_read_bio_Parameters[_ex] function does not have the capability
of specifying a password callback. We should not use the fallback password
callback in this case because it will attempt to send a prompt for the
password which might not be the correct thing to do. We should just not
use a password in that case.
Fixes#21588
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21603)
We're always supposed to add the fallback "unsupported" error if we don't
have anything better. However in some cases this wasn't happening because
we were incorrectly setting "flag_construct_called" - even though the
construct function had failed.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21603)
In the definition of the latest revised LoongArch64 vector instruction manual,
it is clearly pointed out that the undefined upper three bits of each byte in
the control register of the vshuf.b instruction should not be used, otherwise
uncertain results may be obtained. Therefore, it is necessary to correct the
use of the vshuf.b instruction in the existing vpaes-loongarch64.pl code to
avoid erroneous calculation results in future LoongArch64 processors.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21530)
Also fixes a similar regression in X509_VERIFY_PARAM_add0_table().
Commit 38ebfc3 introduced a regression in 3.0.6 that changed the return
value of the two functions above from 1 on success to the number of entries
in the stack. If there are more than one entry then this is a change in
behaviour which should not have been introduced into a stable release.
This reverts the behaviour back to what it was prior to the change. The code
is slightly different to the original code in that we also handle a possible
-1 return value from the stack push function. This should never happen in
reality because we never pass a NULL stack as a parameter - but for the sake
of robustness we handle it anyway.
Note that the changed behaviour exists in all versions of 3.1 (it never had
the original version). But 3.1 should be fully backwards compatible with 3.0
so we should change it there too.
Fixes#21570
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/21576)
Running LSX instructions requires both the hardware support and the
kernel support. The `cpucfg` instruction only tests the hardware
support, causing a SIGILL if the hardware supports LSX but the kernel
does not.
Use `getauxval(AT_HWCAP)` as the ["Software Development and Build
Convention for LoongArch Architectures"][1] manual suggests.
The LOONGARCH_HWCAP_LSX and LOONGARCH_HWCAP_LASX bits are copied from
the manual too. In Glibc 2.38 they'll be provided by <sys/auxv.h> as
well, but they are unavailable in earlier Glibc versions so we cannot
rely on it.
The getauxval syscall and Glibc wrapper are available since day one
(Linux-5.19 and Glibc-2.36) for LoongArch.
Fixes#21508.
[1]:https://github.com/loongson/la-softdev-convention/blob/master/la-softdev-convention.adoc#kernel-constraints
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21509)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21545)
If |q| >= |p| then the q value is obviously wrong as q
is supposed to be a prime divisor of p-1.
We check if p is overly large so this added test implies that
q is not large either when performing subsequent tests using that
q value.
Otherwise if it is too large these additional checks of the q value
such as the primality test can then trigger DoS by doing overly long
computations.
Fixes CVE-2023-3817
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21550)
The pre-existing error cases where DH_check returned zero
are not related to the dh params in any way, but are only
triggered by out-of-memory errors, therefore having *ret
set to zero feels right, but since the new error case is
triggered by too large p values that is something different.
On the other hand some callers of this function might not
be prepared to handle the return value correctly but only
rely on *ret. Therefore we set some error bits in *ret as
additional safety measure.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21524)
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21515)
CLA: trivial
The purpose of adding the conditional operator on line 710 is to check
if the value of the variable 'fplace' exceeds the size of the array
'fconvert', and to reduce the value of 'fplace' by 1, so that later on
we can set the value to zero of the array element with the index 'fplace'
and not make any calls beyond the array edges.
However, the condition on line 710 will always be false, because
the size of 'fconvert' is strictly specified at the beginning of
the 'fmtfp()' function (line 571), so it is reasonable to remove
this conditional operator, as well as the unreachable decrementation
code of the variable 'fplace'.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21325)
Function `X509at_add1_attr()` (crypto/x509/x509_att.c) rejects to add a duplicity into `*x` but it searches in a wrong stack.
Changed to search in `*x`.
CLA: trivial
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21505)
The hardware-assisted ARMv8.2 implementation is already in keccak1600-armv8.pl.
It is not called because the author mentioned that it's not actually obvious
that it will provide performance improvements. The test on Apple M1 Firestorm
shows that the ARMv8.2 implementation could improve about 36% for large blocks.
So let's enable ARMv8.2 accelerated SHA3 on Apple CPU family.
Fixes#21380
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21398)
The DH_check() function checks numerous aspects of the key or parameters
that have been supplied. Some of those checks use the supplied modulus
value even if it is excessively large.
There is already a maximum DH modulus size (10,000 bits) over which
OpenSSL will not generate or derive keys. DH_check() will however still
perform various tests for validity on such a large modulus. We introduce a
new maximum (32,768) over which DH_check() will just fail.
An application that calls DH_check() and supplies a key or parameters
obtained from an untrusted source could be vulnerable to a Denial of
Service attack.
The function DH_check() is itself called by a number of other OpenSSL
functions. An application calling any of those other functions may
similarly be affected. The other functions affected by this are
DH_check_ex() and EVP_PKEY_param_check().
CVE-2023-3446
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21451)
QUIC error code, frame type and reason is in error data
Fixes#21337
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21476)
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21467)
Signed-off-by: lan1120 <lanming@huawei.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21170)
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/21135)
Richard Levitte
Matt Caswell
Dimitri Papadopoulos
Bernd Edlinger
Min Zhou
Pauli
Hugo Landau
Dr. David von Oheimb
Tomas Mraz
Kai Pastor
slontis
Tom Cosgrove
Rohan McLure
Ingo Franzki
Dmitry Belyavskiy
olszomal
Xu Yizhou
Rob Stradling
vl-loz
Neil Horman
3lswear
Dr. David von Oheimb
MscVZoltan
Olga Batyshkina
atishkov
ihciah
zhuchen
Xi Ruoyao
MrRurikov
Adam Šulc
sdlyyxy
lan1120