-
Bug
-
Resolution: Won't Do
-
Major
-
None
-
rhel-8.10
-
None
-
No
-
None
-
rhel-security-crypto
-
ssg_security
-
None
-
False
-
False
-
-
None
-
None
-
None
-
None
-
Unspecified
-
Unspecified
-
Unspecified
-
x86_64
-
None
What were you trying to do that didn't work?
When using OpenSSL in FIPS mode, we see a noticeable overhead from CRYPTO_THREAD_read_lock and CRYPTO_THREAD_UNLOCK. This appears to come from FIPS_selftest_failed
What is the impact of this issue to you?
System performance overhead in an application that uses openssl to encrypt/decrypt data going to disks, where we spend additional CPU time just managing the lock state vs doing the encryption or other application related work.
Please provide the package NVR for which the bug is seen:
openssl 1.1.1k
How reproducible is this bug?:
100% of the time when doing encryption/decryption operations in parallel amongst multiple threads within one of our applications
Steps to reproduce
- Make calls into EVP_CIPHER* (like EVP_CIPHER_CTX_new, EVP_CIPHER_CTX_reset, EVP_CIPHER_CTX_free, EVP_CipherInit)
- Do this in parallel in the same application across multiple threads
- Do perf top / perf record of the application, and locking overhead will show up
Expected results
Not as much locking overhead as there is now
Actual results
More overhead with locking than we'd like