Fork tests are necessary

[beldmit]

On fork a lot of PKCS#11 object handles become irrelevant. We need to have a test like "login-fork-do stuff" to check whether all these handles are dealt with correctly.

[simo5]

Key Handles and Session Handles may be invalidated on fork (depends on how the token driver handles this, if at all).

We already have a global session cache where all sessions are stored. We'll need a new global object cache where all objects are stored.

Upon fork we'll need to (via pthread_atfork ?) intercept the fact that a fork happened, then go through the caches and re-validate each object that is in use and discard all others.

[beldmit]

AFAIR, it also affects slots.

In my code I just cached the pid, but of course pthread_atfork would work

[simo5]

If you just cache the pid, then you will have to test for it before every single operation .. sounds burdensome on the code. I guess it depends on how many entry points you have...

[simo5]

AFAIR, it also affects slots.

Why would it affect slots?

[beldmit]

I don't exactly remember.

[Jakuje]

Note, that in PKCS#11 3.0, there is a flag CKF_INTERFACE_FORK_SAFE which is provided alongside with the interface, which describes this in the new standard:

The returned interface will have fork tolerant semantics. When the application forks, each process will get its own copy of all session objects, session states, login states, and encryption states. Each process will also maintain access to token objects with their previously supplied handles.

https://docs.oasis-open.org/pkcs11/pkcs11-base/v3.0/os/pkcs11-base-v3.0-os.html#_Toc29976546

So unless we have this flag from the interface, we (the provider and the application) should not expect the session objects, session states, login states, ... can be used and the pkcs11-provider needs to reinitialize these and dont assume they will be ok as they are in the software modules. The softhsm2 has a way to simulate this with library.reset_on_fork = true, but given that we are using the p11-kit remoting, the fork of the calling application does not affect the softhsm so testing this will have to wait a bit.

[simo5]

I now expose a intf_flags variable on the provider context that contains the interface flags as/if detected otherwise it is 0.

[simo5]

Introduced with #142