From: Tomas Mraz Date: Tue, 27 May 2025 09:36:31 +0000 (+0200) Subject: Document that FIPS provider cannot be used by multiple libcryptos X-Git-Tag: openssl-3.0.17~29 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=fd3f9b45da2f3a174405377f2497f0127a967980;p=thirdparty%2Fopenssl.git Document that FIPS provider cannot be used by multiple libcryptos Reviewed-by: Matt Caswell Reviewed-by: Paul Dale (Merged from https://github.com/openssl/openssl/pull/27702) (cherry picked from commit 08b2042a20e76472416c8c7c48e479d893ba904f) --- diff --git a/doc/man7/OSSL_PROVIDER-FIPS.pod b/doc/man7/OSSL_PROVIDER-FIPS.pod index 66165bdb0cc..ed15331fb67 100644 --- a/doc/man7/OSSL_PROVIDER-FIPS.pod +++ b/doc/man7/OSSL_PROVIDER-FIPS.pod @@ -421,6 +421,19 @@ validated versions alongside F and F compiled from any release within the same major release series. This flexibility enables you to address bug fixes and CVEs that fall outside the FIPS boundary. +You can load the FIPS provider into multiple library contexts as any other +provider. However the following restriction applies. The FIPS provider cannot +be used by multiple copies of OpenSSL libcrypto in a single process. + +As the provider saves core callbacks to the libcrypto obtained in the +OSSL_provider_init() call to global data it will fail if subsequent +invocations of its OSSL_provider_init() function yield different addresses +of these callbacks than in the initial call. This happens when different +copies of libcrypto are present in the memory of the process and both try +to load the same FIPS provider. A workaround is to have a different copy +of the FIPS provider loaded for each of the libcrypto instances in the +process. + =head1 SEE ALSO L,