fips: explicitly setup cpuid when initialize

[ZenithalHourlyRate]

Fixes: #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

Test

I have tested this branch merged with #24403, and the riscvcap_P inside libcrypto/fips.so are both initialized.

Uncertainties

1. Now cpuid_setup is put after function_id init, and before context/thread/self-test. Putting it before thread init comes from the below snippet, but I do not know whether to put it before context creation or not.

openssl/crypto/init.c

Lines 68 to 74 in a6afe2b

	OPENSSL_cpuid_setup();
	if (!ossl_init_thread())
	goto err;
	if (!CRYPTO_THREAD_init_local(&in_init_config_local, NULL))
	goto err;

2. This behavior should be documented somewhere, where should I put them.

3. Test and coverage for this also needs massive effort. The coverage is also a problem when we gradually remove the constructor behavior of all cpuid_setup (Set OPENSSL_ppccap_P global variable in fips provider context #24399 (comment))

Checklist

• documentation is added or updated
• tests are added or updated

[t8m]

This means OPENSSL_cpuid_setup() will be called twice on platforms that have it as a constructor/DEP init. Should we drop the attribute from it and call it from another call marked as constructor, that won't be compiled into FIPS_MODULE?

[t8m]

This means OPENSSL_cpuid_setup() will be called twice on platforms that have it as a constructor/DEP init. Should we drop the attribute from it and call it from another call marked as constructor, that won't be compiled into FIPS_MODULE?

IMO that should be done at least for the master branch. For stable branches we should IMO skip this call on platforms which mark it as constructor to minimize the changes.

[ZenithalHourlyRate]

Should we drop the attribute from it and call it from another call marked as constructor, that won't be compiled into FIPS_MODULE?

I think libcrypto also does not need such another constructor as crypto/init.c also explicitly initialized cpuid

Also, calling cpuid_setup twice should not be harmful.

[t8m]

I think libcrypto also does not need such another constructor as crypto/init.c also explicitly initialized cpuid

The problem is that this init function might not be called in some circumstances such as when only the deprecated low-level functions are being called by an application.

Also, calling cpuid_setup twice should not be harmful.

Yeah, that's right. And given it is already called twice for libcrypto, let's ignore this issue for now.

[openssl-machine]

This pull request is ready to merge

[t8m]

Merged to all the active branches. Thank you for your contribution.

[sanumesh]

Is this fix already pushed ? When will it be available in branch ?