optimization capabilities missing in openssl fips provider

[sanumesh]

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

[nhorman]

You should not do that. The certificate for the FIPS provider is only valid for the software defined algorithms in the FIPS provider. Enabling hardware acceleration within the FIPS provider nullifies that validation.

[simo5]

this is not right,
it depends on how you do validation.
It is quite normal to ACVP test the same algorithms with different optimizations so that both software and HW accelerate implementations can be covered.

[beldmit]

Not sure I get. The *cap* variables just switch between different SW paths...

[t8m]

IMO @nhorman is correct, but also incorrect, depending on ways on how you look at the problem. I would call this a bug as this is certainly unintentional side effect of having the capability variable unset in the FIPS provider's copy. I actually wonder if the FIPS provider on x86_64 and aarch64 has the same problem. If so, and that is likely, then this is definitely a problem and unintended.

On the other hand the ppc64 platforms where those accelerating instructions are available are not among those platforms where the OpenSSL FIPS module is tested and validated. Due to this it is much closer to FIPS compliance to use the non-accelerated default implementation that is being used due to this issue.

With x86_64 and aarch64 this is much worse issue as it was fully intended to have the accelerated code-paths tested and validated but if this issue is present on these platforms, these code paths actually weren't tested and validated and they are not used at all. Which is fairly bad due to much worse properties in terms of performance and side-channel resistance of the C implementation.

[simo5]

Why was this moved to a discussion?
If HW capabilities are not settable in a provider this really looks like an obvious bug.

[nhorman]

thats my fault, I had assumed that our current FIPS validation intended to not enable hardware acceleration. I'll move this back

[nhorman]

recreated here:
#23979

[t8m]

BTW fortunately x86_64 is not affected by this issue. According to my testing the CPU feature detection works fine there even for the fips provider.

[slontis]

Not sure about how this gets called,
but I assume the attribute ((constructor)) is doing its magic for GNUC related platforms at least?

[slontis]

@nhorman FYI..
In the security policy (section 3)
https://www.openssl.org/source/fips-doc/openssl-3.0.9-security-policy-2024-01-12.pdf you will see 2 entries for each tested platform, one is the PAA entry.
AIX is not listed as a platform that is tested with PAA.

[t8m]

Not sure about how this gets called, but I assume the attribute ((constructor)) is doing its magic for GNUC related platforms at least?

But surprisingly the attribute((constructor)) is applied only on ppc and arm OPENSSL_cpuid_setup() functions. It is not applied to the same on x86 and other architectures.

So I think something else plays here. No idea what, though.

[ZenithalHourlyRate]

But surprisingly the attribute((constructor)) is applied only on ppc and arm OPENSSL_cpuid_setup() functions. It is not applied to the same on x86 and other architectures.

So I think something else plays here. No idea what, though.

$ head x86_64cpuid.s

.hidden OPENSSL_cpuid_setup
.section        .init
        call    OPENSSL_cpuid_setup

It is not attribute but directly .init section. Checking fips.so for x86, symbol _init is in .init_array and that symbol just calls cpuid_setup.

[t8m]

Ah, thank you for this explanation.