Problems with automatic pkcs11 reinit on fork

Alon Bar-Lev alon.barlev at
Sat Oct 8 19:16:36 CEST 2011


Some thoughts....

1. I always assued that p11-kit was a transparent PKCS#11 provider
that does extra functionality on behalf proxied providers. Maybe I am

2. If (1) is correct, requesting application to do some extra logic if
the specific p11-kit is loaded is something that should be avoided.,

3. If (1) is correct, and application is already using PKCS#11, it
should follow the spec and do <something> special when fork()ing, and
nothing is needed.

4. Most provides miss this requirement, and even after
re-initialization do not work properly. This is *THE* bug of providers
when vendors port their provider into *POSIX, and won't be fixed

5. Doing that transparent requires:

a. Make sure application is designed properly to re-initialize any
handle that is invalidate.

b. Record pid of initialized process, and monitor all C_ functions for
uninitialized process.

c. Keep refcount for each C_ method, and wait for refcount=0 before
fork(), this should be done at all process threads! (Most common,
thread that polls for slot status).

d. Free locks of all threads other than fork() thread before fork().

e. Reinitialize after fork().


On Sat, Oct 8, 2011 at 8:19 AM, Stef Walter <stefw at> wrote:
> In p11-kit we've copied the pakchois behavior of automatically
> reinitializing when a fork happens. In PKCS#11 an application using
> PKCS#11 modules has to call C_Initialize after a fork to reinitialize
> the smart card driver.
> The automatic reinitialization behavior of p11-kit is sort of nice from
> the perspective of the consumers of the library, however it causes
> performance problems when it's automatic.
> For example if a process that's using p11-kit forks/execs another
> executable, then all the PKCS#11 providers are reinitialized after the
> fork and before the exec.
> Perhaps we should change p11-kit so that it's fork aware, and zeros its
> initialization ref counts, but expects the user of the library to
> actually reinitialize after a fork.
> For example, in the case of gnutls, on the next use of PKCS#11 after a
> fork gnutls would need to call p11_kit_initialize_registered() again.
> How does that sound? Alon, I hope it's okay that I've CC'd you. You
> have extensive experience with how applications deal with this issue, so
> I figured you may have valuable advice.
> Cheers,
> Stef

More information about the Gnutls-devel mailing list