Problems with automatic pkcs11 reinit on fork

[Stef Walter]

On 10/10/2011 11:40 PM, 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.
>
> I wouldn't think gnutls as a special case, but rather as just another
> user of the p11-kit framework (glue). Having an API that says please
> during fork do that, but if you do fork very often then wait until the
> next pkcs11 operation and then do it, or you become slow... sounds
> really ugly. Of course there could be a fix for gnutls because the API
> is limiting pkcs11 operations, but other users of p11-kit would have
> exactly the same problem and a fix might not be so straightforward.
>
> A viable solution I see is wrapping pkcs11 calls. I see how you did that
> in gnutls so it looks pretty straightforward that could be added and
> exported from p11-kit.

Yes, that's true. I agree, it seems like that's the cleanest way to 
accomplish reinitializing after a fork.

As discussed previously, the caller of p11-kit (like gnutls) would also 
need to be made aware of the reinitialization, via a callback perhaps, 
so that it can clear out its cached information about the state of the 
PKCS#11 modules. These two aspects are obviously not mutually exclusive.

Cheers,

Stef