Problems with automatic pkcs11 reinit on fork
stefw at collabora.co.uk
Sun Oct 30 10:38:53 PDT 2011
On 2011-10-29 14:23, Nikos Mavrogiannopoulos wrote:
> On 10/10/2011 06:17 PM, Stef Walter wrote:
>>> 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.
> Hi any update on that (on the p11-kit part). Would p11-kit provide a
> callback when reinitialization occurs, or should gnutls use pthread_atfork?
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
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
More information about the p11-glue