Problems with automatic pkcs11 reinit on fork

Nikos Mavrogiannopoulos n.mavrogiannopoulos at
Fri Dec 23 13:21:11 PST 2011

On Fri, Dec 23, 2011 at 7:41 PM, Stef Walter <stefw at> wrote:

>>> So what I've been meaning to do is one or both of the following:
>>>  * Provide a function/macro which callers p11-kit can use to check if a
>>>   fork has occurred.
>>>  * Merge in something like the pakchois API, so that we can do the
>>>   reinitialization checks.
>> If you need any help on the latter let me know.
> So I've worked on this plan a bit more, and run into a problem with the
> latter option. Seems like a showstopper for that option.
> Many PKCS#11 modules do not lock their C_Initialize and C_Finalize for
> concurrent access eg: NSS libsoftokn. The PKCS#11 spec alludes to this
> behavior by stating:
> "An application becomes a “Cryptoki application” by calling the
> Cryptoki function C_Initialize (see Section 11.4) from one of its
> threads; after this call is made, the application can call other
> Cryptoki functions."
> This means we cannot automatically reliably initialize after a fork on
> the first PKCS#11 function that is incidentally called :(

Hi Stef,
 I don't know if I  understand the issue correctly, but
why is that a stopper? Couldn't p11-kit use some internal mutexes
only for reinitialize on fork?


More information about the p11-glue mailing list