Failures to load fips provider result in cryptic error due to bundling of conditionals

[ngie-eign]

One of the common issues I've run into dealing with the FIPS provider is that the error handling in selftest.c isn't incredibly helpful. In particular, this line bundles together 2 conditionals to ensure the second conditional doesn't result in a SIGSEGV from a NULL pointer dereference...

openssl/providers/fips/self_test.c

Lines 338 to 339 in e1fd043

	if (st == NULL
	|| st->module_checksum_data == NULL) {

This results in this cryptic error though:

+ env 'OPENSSL_CONF=$PWD/ossl_cnf_43Rk3C' openssl list -provider fips
list: unable to load provider fips
Hint: use -provider-path option or OPENSSL_MODULES environment variable.
00206134EF5C0000:error:1C8000D5:Provider routines:SELF_TEST_post:missing config data:/usr/src/crypto/openssl/providers/fips/self_test.c:275:
00206134EF5C0000:error:1C8000E0:Provider routines:ossl_set_error_state:fips module entering error state:/usr/src/crypto/openssl/providers/fips/self_test.c:373:
00206134EF5C0000:error:1C8000D8:Provider routines:OSSL_provider_init_int:self test post failure:/usr/src/crypto/openssl/providers/fips/fipsprov.c:707:
00206134EF5C0000:error:078C0105:common libcrypto routines:provider_init:init fail:/usr/src/crypto/openssl/crypto/provider_core.c:932:name=fips

Separating out the two conditionals would (at the very least) allow end-users to better determine what condition is causing the fips provider to not load.
(in my particular scenario, it's the second case that's failing)

Contents of $OPENSSL_CONF

config_diagnostics = 1

# NB: the full path was omitted on purpose.
.include ${ENV::PWD}/ossl_cnf_43Rk3C.fips

openssl_conf = openssl_init

# Need to specify the absolute path here.

[openssl_init]
providers = provider_sect

# Load base + fips (default doesn't jive with fips).
[provider_sect]
base = base_sect
fips = fips_sect

[base_sect]
activate = 1

"fipsmodule.cnf" (ossl_cnf_43Rk3C.fips)

[fips_sect]
activate = 1
install-version = 1
conditional-errors = 1
security-checks = 1
module-mac = 61:78:FA:4A:37:53:45:AE:3E:59:D6:6B:4A:AD:B1:6E:66:1F:98:AF:7B:F8:CC:04:35:44:B7:69:84:6D:F9:B9
install-mac = 41:9C:38:C2:8F:59:09:43:2C:AA:2F:58:36:2D:D9:04:F9:6C:56:8B:09:E0:18:3A:2E:D6:CC:69:05:04:E1:11
install-status = INSTALL_SELF_TEST_KATS_RUN

[mattcaswell]

It seems reasonable to me to separate the conditionals. Adding "help wanted" to this issue.

[t8m]

Not sure what would be the improvement as the first condition is not going to fail ever - it could be even converted to an ossl_assert(). The error message SELF_TEST_post:missing config data is IMO good enough.

The config data is in your case missing because you've placed .include before openssl_conf = openssl_init which means openssl_conf = openssl_init is inside [fips_sect] and is thus ineffective.

[ngie-eign]

@mattcaswell : I can provide a patch if desired.
@t8m : being able to trace back what the exact error was could be helpful if there are multiple items that could have triggered the failure. In this case, I realize now that I was missing a section because I hadn't defined that section early enough, but in reality... it took me over 2 hours to figure that out (the messages in and of themselves were not helpful and the documentation doesn't make this fact clear).
I understand that you might not see much value, but... if there are more reasons for the parameters in st being NULL, it's only going to get more and more confusing to identify what actually isn't working since there isn't an adequate diagnostic command for dumping OpenSSL configuration (today), and the config format is not standard (is there a provided or external config validator tool that I'm not aware of...?).

[t8m]

The problem is that at this place in the code there is not much else you can report than missing checksum data.

Something could be done in fips_get_params_from_core() - there we could report that some mandatory params are missing - i.e. the module-mac param is not provided from core. It would still not resolve the problem that the config file parser does not actually properly load the provider params because of the issue you had there with misplacing the .include.