Problems with automatic pkcs11 reinit on fork

[Stef Walter]

On 11/03/2011 01:16 PM, Nikos Mavrogiannopoulos wrote:
> On Sun, Oct 30, 2011 at 6:38 PM, Stef Walter <stefw at collabora.co.uk> wrote:
>> It turns out that pthread_atfork() callbacks is really only supposed to
>> call async-signal-safe functions. This is specified in some versions of
>> the POSIX documentation, and aluded to in others. It *seems* that on
>> Linux the 'child' handler can get away with doing more, but that is non
>> portable :(
>> I haven't removed the behavior from p11-kit which auto-reinitializes,
>> even though this is broken considering the above limitation.
>> 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."

What this means in practice is that many PKCS#11 modules do not support
concurrent calls to C_Initialize.

This means we cannot automatically reliably initialize after a fork on
the first PKCS#11 function that is incidentally called :(

What this means is that in order to handle forking reliably in libraries
that use PKCS#11 the entire stack needs to be more aware of when a fork
occurs and reinitialization needs to occur. In reality this is already
the case in any application that uses threads.

Am I understanding this correctly.

Cheers,

Stef