Problems with automatic pkcs11 reinit on fork
stefw at collabora.co.uk
Mon Oct 10 09:17:29 PDT 2011
On 10/09/2011 11:13 PM, Nikos Mavrogiannopoulos wrote:
> On 10/08/2011 05:39 PM, Stef Walter wrote:
>> When it comes to PKCS#11, we cannot make forking transparent for gnutls
>> or any other library or application.
>>> Couldn't this be handled entirely within p11-kit? I.e. at fork instead
>>> of initializing everything, mark as everything being uninitialized. Then
>>> (a) either reinitialize everything on the first pkcs11 call,
>> We don't wrap every pkcs11 call, so sadly this wouldn't work, see the
>> problem with transparency above.
> What if you wrap every call just like pakchois did. Then it would be
There was some talk of merging pakchois into p11-kit. It hasn't been the
focus of p11-kit to be a wrapper library abstracting all of PKCS#11,
although it does abstract the loading and initializing.
>> or (b)
>>> provide a call like p11_kit_reinitialize_if_needed() or so.
>> I guess we can do this or something like it. We could have a macro that
>> checks a global variable to make this a very fast check.
> This would be problematic when you could also have multiple threads
> (e.g. the way apache works). In most of the cases where multiple
> initialization doesn't really matter it wouldn't be a problem, but here
> multiple initialization might have unexpected outcome. Thus some kind of
> locks would also be required.
You're right. I ran into this problem the other day independently of
In particular, some PKCS#11 modules do not do locking inside their
C_Initialize or C_Finalize. They expect that those methods are called
from a single thread and not concurrently. NSS's libsoftkn3 is a module
So I've committed fixes to p11-kit just this morning, which prevent
concurrent initialization, and handle this case correctly within the
refcounting framework of p11-kit.
>> But would it make more sense for gnutls to listen to pthread_atfork()
>> and clear out its pkcs#11 state?
> Then I'd have exactly the same problem that you have. Performance issues
> :) It might be better for this issue to be solved once and for all users
> of p11-kit.
It's pretty hard to do this correctly at the p11-kit layer. We cannot
transparently hide the fact that all of a sudden all slots, token info,
sessions, objects, and other handles have been invalidated. Therefore
any structures that gnutls is holding must also be cleared on fork.
Forgive me if I'm missing something, but the only way I see to solve
this part of the problem is for p11-kit to notify gnutls that any and
all PKCS#11 state is invalid. gnutls would then start from a clean
pkcs#11 state. I'll work on some patches for gnutls.
More information about the p11-glue