optimization capabilities missing in openssl fips provider #23979
Labels
Comments
t8m
added
triaged: bug
nhorman
added
the
severity: important
|
I'm guessing the easy fix is to call |
nhorman
added
help wanted
and removed
severity: important
1 task
ZenithalHourlyRate
added a commit
to ZenithalHourlyRate/openssl
that referenced
this issue
May 16, 2024
Fixes: openssl#23979 Previously fips module relies on OPENSSL_cpuid_setup being used as constructor by the linker to correctly setup the capability vector, either via .section .init (for x86_64) or via __attribute__((constructor)). This would make ld.so call OPENSSL_cpuid_setup before the init function for fips module. However, this early constructing behavior has several disadvantages: 1. Not all platform/toolchain supports such behavior 2. Initialisation sequence is not well defined, and some function might not be initialized when cpuid_setup is called 3. Implicit path is hard to maintain and debug
2 tasks
openssl-machine
pushed a commit
that referenced
this issue
May 22, 2024
Fixes: #23979 Previously fips module relied on OPENSSL_cpuid_setup being used as constructor by the linker to correctly setup the capability vector, either via .section .init (for x86_64) or via __attribute__((constructor)). This would make ld.so call OPENSSL_cpuid_setup before the init function for fips module. However, this early constructing behavior has several disadvantages: 1. Not all platform/toolchain supports such behavior 2. Initialisation sequence is not well defined, and some function might not be initialized when cpuid_setup is called 3. Implicit path is hard to maintain and debug Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #24419) (cherry picked from commit a192b24)
openssl-machine
pushed a commit
that referenced
this issue
May 22, 2024
Fixes: #23979 Previously fips module relied on OPENSSL_cpuid_setup being used as constructor by the linker to correctly setup the capability vector, either via .section .init (for x86_64) or via __attribute__((constructor)). This would make ld.so call OPENSSL_cpuid_setup before the init function for fips module. However, this early constructing behavior has several disadvantages: 1. Not all platform/toolchain supports such behavior 2. Initialisation sequence is not well defined, and some function might not be initialized when cpuid_setup is called 3. Implicit path is hard to maintain and debug Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #24419) (cherry picked from commit a192b24)
openssl-machine
pushed a commit
that referenced
this issue
May 22, 2024
Fixes: #23979 Previously fips module relied on OPENSSL_cpuid_setup being used as constructor by the linker to correctly setup the capability vector, either via .section .init (for x86_64) or via __attribute__((constructor)). This would make ld.so call OPENSSL_cpuid_setup before the init function for fips module. However, this early constructing behavior has several disadvantages: 1. Not all platform/toolchain supports such behavior 2. Initialisation sequence is not well defined, and some function might not be initialized when cpuid_setup is called 3. Implicit path is hard to maintain and debug Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #24419) (cherry picked from commit a192b24)
openssl-machine
pushed a commit
that referenced
this issue
May 22, 2024
Fixes: #23979 Previously fips module relied on OPENSSL_cpuid_setup being used as constructor by the linker to correctly setup the capability vector, either via .section .init (for x86_64) or via __attribute__((constructor)). This would make ld.so call OPENSSL_cpuid_setup before the init function for fips module. However, this early constructing behavior has several disadvantages: 1. Not all platform/toolchain supports such behavior 2. Initialisation sequence is not well defined, and some function might not be initialized when cpuid_setup is called 3. Implicit path is hard to maintain and debug Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #24419) (cherry picked from commit a192b24)
jvdsn
pushed a commit
to jvdsn/openssl
that referenced
this issue
Jun 3, 2024
Fixes: openssl#23979 Previously fips module relied on OPENSSL_cpuid_setup being used as constructor by the linker to correctly setup the capability vector, either via .section .init (for x86_64) or via __attribute__((constructor)). This would make ld.so call OPENSSL_cpuid_setup before the init function for fips module. However, this early constructing behavior has several disadvantages: 1. Not all platform/toolchain supports such behavior 2. Initialisation sequence is not well defined, and some function might not be initialized when cpuid_setup is called 3. Implicit path is hard to maintain and debug Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#24419)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Discussed in #23978
Originally posted by sanumesh March 26, 2024
Hello
I am using openssl 3.0.10 version and have built the fips provider using the make enable_fips flags for aix-cc platform.
However the openssl speed command shows that it is not using the hardware capabilities of Power, and instead uses the software implementations of the algorithms.
This is seen when fips provider is enabled in the openssl.cnf configuration file (with default disabled).
The issue is that the OPENSSL_cpuid_setup function which sets the power hardware capabilities (OPENSSL_ppccap_P variable) gets called only in the context of default provider.
Since fips provider is loaded as a shared object, it has its own copy of OPENSSL_ppccap_P which gets initialized to 0 as we do not call OPENSSL_cpuid_setup function in the context of FIPS provider. Since this value is 0, any algorithm implementation calls done with fips provider uses the software based implementation of the algorithms.
Can you advice how to fix this?
Thanks
The text was updated successfully, but these errors were encountered: