a new config option _no_rcu_ is added into HT_CONFIG. When _no_rcu_ is
set then hashtable can be guarded with any other locking primitives,
and behives as ordinary hashtable. Also, all the impact of the
atomics used internally to the hash table was mitigated.
RCU performance
# INFO: @ test/lhash_test.c:747
# multithread stress runs 40000 ops in 40.779656 seconds
No RCU, guarded with RWLOCK
# INFO: @ test/lhash_test.c:747
# multithread stress runs 40000 ops in 36.976926 seconds
Signed-off-by: Nikola Pajkovsky <nikolap@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28677)
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28639)
during memfail testing:
https://github.com/openssl/openssl/actions/runs/16794088536/job/47561223902
We get lots of test failures in ossl_rcu_read_lock. This occurs
because we have a few cases in the read lock path that attempt mallocs,
which, if they fail, trigger an assert or a silent failure, which isn't
really appropriate. We should instead fail gracefully, by informing the
caller that the lock failed, like we do for CRYPTO_THREAD_read_lock.
Fortunately, these are all internal apis, so we can convert
ossl_rcu_read_lock to return an int indicating success/failure, and fail
gracefully during the test, rather than hitting an assert abort.
Fixesopenssl/project#1315
Reviewed-by: Paul Yang <paulyang.inf@gmail.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28195)
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28102)
Also add support for ML-KEM in CMS (draft-ietf-lamps-cms-kyber).
Add the -recip_kdf and -recip_ukm parameters to `openssl cms -encrypt`
to allow the user to specify the KDF algorithm and optional user
keying material for each recipient.
A provider may indicate which RecipientInfo type is supported
for a key, otherwise CMS will try to figure it out itself. A
provider may also indicate which KDF to use in KEMRecipientInfo
if the user hasn't specified one.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27681)
Add HKDF-SHA256, HKDF-SHA384 and HKDF-SHA512 which are versions
of HKDF that have the digest pre-set. The digest cannot be changed
for contexts of these types.
RFC 8619 defines algorithm identifiers for these combinations.
These algorithm identifiers will be used in future features, e.g.
KEMRecipientInfo.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/27247)
The slh_dsa fuzzer predicts failure in EVP_message_sign_init in the
event we pass a context_string param of more than 255 bytes. That makes
for an accurate prediction, but only if we actually create the param.
augment the setting of exepct_rc_init to be determined not only by our
allocation of a > 255 byte message, but also on selector bit 1, which
determines if we create the parameter at all.
Fixes https://oss-fuzz.com/testcase-detail/4807793999937536
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/26884)
construction of int params holds a pointer to an int rather than an int
value, so we need to use separate variables when constructing separate
int params.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26851)
oss-fuzz issue:
https://issues.oss-fuzz.com/issues/397734693
Fails because the fuzzer occasionaly provides inputs which drives the
fuzzer to create an octet-string for the context_string param which
violates the 255 byte constraint documented on that parameter.
Fix it by detecting that condition, expecting failure in the call to
EVP_sign_message_init, and bailing out when it occurs.
Fixesopenssl/project#1109
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26851)
Current preforms the following operations
1) Generates arbitrary key pairs
2) Generates key pairs with parameters (both correct and incorrect)
based on fuzzer input buffer
3) Exports and re-imports keys, confirming validity
4) Preforms Sign and Verify operations with optional parameters based on
fuzzer input buffer
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26708)
Centralise the storage of the override in the QUIC_ENGINE rather than in
the QUIC_CONNECTION. We can now set the override on any type of QUIC SSL
object as needed.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25457)
Add an initial version of an ML-DSA fuzzer. Exercises various ML-DSA
appropriate APIs. Currently it is able to randomly:
1. Attempt to create raw public private keys of various valid and invalid sizes
2. Generate legitimate keys of various sizes using the keygen api
3. Perform sign/verify operations using real generated keys
4. Perform digest sign/verify operations using real generated keys
5. Do an export and import of a key using todata/fromdata
6. Do a comparison of two equal and unequal keys
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26685)
Add an inital version of an ML-KEM fuzzer. Exercises various ML-KEM
appropriate apis, as a fuzzer does. Currently it is able to randomly:
1) Attempt to create raw public private keys of various valid and
invalid sizes
2) Generate legitimate keys of various sizes using the keygen api
3) Preform encap/decap operations using real generated keys
4) Do a shared secret derivation using 2 keys
5) Do an export and import of a key using todata/fromdata
6) Do a comparison of two equal and unequal keys
Its not much to start, but it should be fairly extensible
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26657)
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26321)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24754)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24754)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24754)
It is unlikely we would need more than 4000 names and even
with more names (up to 8192) it would still work, just
the performance fo the namemap would degrade.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/24504)
Also build it in the FIPS provider too and properly
report error on insert when hashtable cannot be grown.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/24504)
Add full key matching to hashtable
the idea is that on a hash value match we do a full memory comparison of
the unhashed key to validate that its actually the key we're looking for
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24504)
Keep us from spinning forever doing huge amounts of math in the fuzzer
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/25013)
Sub-OIDs for {iso(1) identified-organization(3) dod(6) internet(1)
private(4) enterprise(1) 45605} are recorded in the document "Wi-SUN
Assigned Value Registry" (WAVR).
OID id-on-hardwareModule is defined in RFC 4108.
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23428)
Move the switch to print a distinguished name inside the
switch by the printed attribute type, otherwise a malformed
attribute will cause a crash.
Updated the fuzz corpora with the testcase
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/25087)
The quic-srtm fuzzer uses a loop in which an integer command is
extracted from the fuzzer buffer input to determine the action to take,
switching on the values between 0 and 3, and ignoring all other
commands. Howver in the failing fuzzer test case here:
https://oss-fuzz.com/testcase-detail/5618331942977536
The buffer provided shows a large number of 0 values (indicating an SRTM
add command), and almost no 1, 2, or 3 values. As such, the fuzzer only
truly exercises the srtm add path, which has the side effect of growing
the SRTM hash table unboundedly, leading to a timeout when 10 entries
need to be iterated over when the hashtable doall command is executed.
Fix this by ensuring that the command is always valid, and reasonably
distributed among all the operations with some modulo math.
Introducing this change bounds the hash table size in the reproducer
test case to less than half of the initially observed size, and avoids
the timeout.
Fixesopenssl/project#679
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24827)
Found by running the checkpatch.pl Linux script to enforce coding style.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22097)
strnlen() is not portable. It is preferable to use the wrapper.
Fixes: #24908
Signed-off-by: Randall S. Becker <randall.becker@nexbridge.ca>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/24912)
The fuzzer was reporting a spurious timeout due to excessive numbers of
commands in a single file. We limit the number of commands to avoid this.
Found by OSSFuzz
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24831)
These checks still take too long time on clusterfuzz
so they are longer than the timeout limit.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/24781)
Support for the targetingInformation X.509v3 extension defined in ITU-T
Recommendation X.509 (2019), Section 17.1.2.2. This extension is used
in attribute certificates.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22206)
Test recipe 99-test_fuzz_provider.t added.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22964)
we extract several values (uint16_t and uint64_t from the fuzzer buff
passed in, but they weren't aligned on 2 and 8 byte boundaries. Adjust
the fuzzer to memcpy data to the target variables to avoid unalignment
issues
Fixes#24272
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/24276)
Frederik Wedel-Heinen
Nikola Pajkovsky
Bob Beck
openssl-machine
Neil Horman
Eugene Syromiatnikov
Michael Baentsch
Daniel Van Geest
Tomas Mraz
icy17
Burkov Egor
Andrew Dinh
Matt Caswell
Viktor Dukhovni
Jonathan M. Wilbur
Mathis Marion
Dimitri Papadopoulos
Randall S. Becker
Max Ammann
Damian Hobson-Garcia