Multiple Callers per Process

This page tracks issues to do with multiple uncoordinated callers in a single process stepping on each other's toes. This may happen when:

At it currently stands, various parts of a larger application may be written in different styles, perhaps different languages and so on. Various callers will (through various layers) try to initialize modules or create sessions and perform PKCS#11 operations. These then fail in various ways if the applications do not respect one another.

This may be material for a profile, or it may be possible to fix these items in the spec.

Current solutions?

C_Initialize thread safety and reference counting

C_Initialize is not currently thread safe (we should probably note this more explicitly). We do mention it should only be called once, but good to make this clearer. Although obviously this is a particularly tough requirement, and one that would be nice to change in in a future version.

Fixing this, so C_Initialize is thread safe, and coordinated between multiple callers (ie: support multiple C_Initialize calls which must be matched with equal C_Finalize calls before actual finalization takes place) seems like it would be more of a long term thing to fix.


This is obviously a big problem when multiple uncoordinated callers are using PKCS#11. We should recommend against using C_CloseAllSessions in routine operations, and only in direct response to user actions (such as an eject button), after which he/she would expect other things doing crypto operations to stop/fail.

C_CloseSession, C_CloseAllSessions and login state

We need to make clear that any assumptions about the login state after calling one of these functions is inherently racy. Another thread (or uncoordinated caller) could open a session which races with the close call.

C_Login and CKU_SO

Why is there a limitation that CKU_SO can only log in if no other read-only sessions exist? This seems arbitrary, and is particularly awkward when there are multiple callers of PKCS#11 in a single process. Does Solaris enforce this? They use PKCS#11 as their standard crypto interface, and the chance of multiple callers within a process is high.

Code written to enumerate objects might open sessions read-only sessions if write access is unecessary. However this would cause a concurrent login as CKU_SO to fail.

If the intent is to prevent using CKU_SO when any other callers are present then we should change it so that CKU_SO fails if any other sessions are currently open.


... this page is incomplete

MultipleCallersPerProcess (last edited 2013-03-21 15:30:46 by stefw)