Prevent multiple initializations

[The-Mule]

Describe the feature

Some applications might load the provider explicitly. At the same time if openssl contains provider configuration, it initialize it too. This can lead to some potential problems, e.g. the one described in https://issues.redhat.com/browse/RHEL-62713. If possible, the pkcs11-provider should prevent multiple initializations by some kind of locking mechanism.

Expected behavior

Application is able to correctly use the pkcs11-provider even when it explicitly loads it while it is already activated by openssl configuration.

[beldmit]

I'm not sure if it's a provider feature. Application should call OSSL_PROVIDER_available at startup to check whether the provider is available

[simo5]

Applications should be able to cretae different context and load the provider on each multiple times, though, so I think we need to do some checking

[beldmit]

OSSL_PROVIDER_available accept libctx - but the attempt to load the same provider into the same context several times looks suspicious to me.

[simo5]

loading in a context that already has the provider initialized is something probably openssl should bail on on its own, and will not be supported. But I am thinking of cases where the provider is loaded in multiple different contexts, I need to verify that is ok.

[beldmit]

Yes, the test is worth having

[The-Mule]

Hm, libssh is using exactly this https://gitlab.com/libssh/libssh-mirror/-/blob/master/src/pki_crypto.c#L2785 and yet the provider ends up initialized multiple times. This code is called for each key specified by uri. I would assume that once provider is part of the openssl config (and activated there) then OSSL_PROVIDER_available(NULL, "pkcs11") returns true (hence libssh will nevert attempt to load it itself (cc @Jakuje, @sahanaprasad07).

[simo5]

I see a much larger issue with libssh code, namely they are interfering with the default OpenSSL context.
that is a big issue, libssh should never touch the default context, it should allocate its own libssl context and reference it from whatever libssh context it has. (and if libssh does not have a context, it needs to grow one asap).

[Jakuje]

I think we do not have a separate openssl context. I created https://gitlab.com/libssh/libssh-mirror/-/issues/278

[Jakuje]

We discussed this a bit over last couple of days and it looks like the libssh does not have the issue of multiple initializations. The pkcs11-provider is intialized correctly only once, but before we configure the test tokens, which leads to the failures. The proposed workaround for the upstream test suite would be to make sure we do not initialize pkcs11 provider too early by not using the global openssl configuration file:
https://gitlab.com/libssh/libssh-mirror/-/merge_requests/543

Usage of application specific openssl context would make it much more complicated, but it is still something we might consider in the future.

[simo5]

The case I am worried about is a case where an application crates a new libctx and then decides to load an alternative config with a completely different token (like a softoken or a proprietary HSM driver).
In this case we need to ensure that the global context handling pointers to slots and configs for resets on fork() will properly handle this case and not cause issues.