[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with automatic pkcs11 reinit on fork

From: Stef Walter
Subject: Re: Problems with automatic pkcs11 reinit on fork
Date: Mon, 10 Oct 2011 18:10:32 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

Thanks Alon, very helpful.

On 10/08/2011 07:16 PM, Alon Bar-Lev wrote:
1. I always assued that p11-kit was a transparent PKCS#11 provider
that does extra functionality on behalf proxied providers. Maybe I am

Yes, that's one way to use p11-kit for applications that are not aware of p11-kit. However in the case of gnutls and other applications aware of p11-kit the applications are invoked directly.

However p11-kit does not aspire to be a wrapper library for PKCS#11. At least not yet ... there was some talk of merging pakchois into p11-kit, but it hasn't been p11-kit's core focus to try and abstract away PKCS#11.

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.

Good point. Right, that makes sense. Handling forking correctly is an integral part of using PKCS#11. It may be that a wrapper library can hide this away, but it would be an extremely leaky abstraction.

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

I see :/

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().

Right, that's a tough set of requirements. I might add that for requirement 'e', one cannot simply reinitialize inside a callback called from pthread_atfork() or similar. NSS and some other PKCS#11 modules use pthread_atfork() to watch for forks and set their internal state to uninitialized, so there's an inherent race condition here.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]