New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FIPS provider ossl_prov_is_running() is slow when running threads with PBKDF2 #21179
Comments
@paulidale Is this code useful for you? (It is just a cutdown version of threadtest.c) |
Could we, when we are calling ossl_prov_is_running() from within the provider, avoid the locking altogether? Or even assume that we must be already running when we are inside the FIPS provider call. |
On the rare case of error where it changes state, do we care that much? |
Perhaps |
Memory barriers are probably sufficient rather than atomic. I suspect they could be quite weak ones. As rule this value won't change after initialisation. |
Even if the value did change after initialization, certification labs would probably only care that it is eventually consistent. Let's say, for example, that we'd start changing the state to error whenever a pairwise consistency test after key generation fails, and that key generation happens in the presence of threads. At what point would a completely unrelated cryptographic operation in a different thread have to stop working? I'd argue (and last time we brought this up our certification lab agreed) that it doesn't have to be immediate, it's enough to just eventually stop accepting new operations. It should be immediately consistent within a thread, but that's simple. |
The FIPS provider accesses it's current state under lock. This is overkill, little or no synchronisation is actually required in pracice (because it's essentially a read only setting). Switch to using TSAN operations in preference. Fixes openssl#21179
The FIPS provider accesses it's current state under lock. This is overkill, little or no synchronisation is actually required in practice (because it's essentially a read only setting). Switch to using TSAN operations in preference. Fixes openssl#21179
The FIPS provider accesses it's current state under lock. This is overkill, little or no synchronisation is actually required in practice (because it's essentially a read only setting). Switch to using TSAN operations in preference. Fixes openssl#21179
The FIPS provider accesses it's current state under lock. This is overkill, little or no synchronisation is actually required in practice (because it's essentially a read only setting). Switch to using TSAN operations in preference. Fixes #21179 Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #21187) (cherry picked from commit 8e9ca33)
The FIPS provider accesses it's current state under lock. This is overkill, little or no synchronisation is actually required in practice (because it's essentially a read only setting). Switch to using TSAN operations in preference. Fixes #21179 Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #21187) (cherry picked from commit 8e9ca33)
I wanted to write a simple threaded test running a KDF to see what differences there were in speeds, when comparing master, and 3.0.9
plus fips provider from both places.. (In particular is the internal fetch time significant).
I noticed when running that the following in either master or 3.0.9
LD_LIBRARY_PATH=. ./test/mythreadtest -fips -config test/fips.cnf
took considerably more time than:
./test/mythreadtest -config test/default.cnf
Enabling and comparing cachegrind outputs (in debug) e.g
LD_LIBRARY_PATH=. valgrind --tool=callgrind --instr-atstart=no ./test/threadstest -config test/default.cnf
I could see that there are 2.5 million calls to ossl_prov_is_running(). Commenting out the read lock inside this function makes the time closer to the default provider times.
The text was updated successfully, but these errors were encountered: