Re: Problems with automatic pkcs11 reinit on fork

[Stef Walter]

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
> possible.

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 
this issue.

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 
like this.

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.

Cheers,

Stef