[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Proposal: Supporting multiple callers in process
On 04/15/13 14:00, Stef Walter wrote:
There are several issues related to having multiple callers of a PKCS#11 module in a process. I propose we either:
There is also a semi-related set of issues to do with what happens on fork() that we should also discuss - the fork saftey issues have caused us more problems on the Solaris/Java boundary than thread safety issues.
a) Clarify these issues in the spec so that multiple callers can use a token within certain expectations.
I'd rather we do this and where necessary update the spec to allow things as you have detailed below.
b) Define this as part of a profile where adhering callers are well behaved with regards to other callers in the same application.
More details here: https://wiki.oasis-open.org/pkcs11/MultipleCallersPerProcess This is not meant to be an attempt at virtualizing PKCS#11 tokens or anything like that. In particular the login state of a token will always be per-process (what we currently call an application in PKCS#11). However with certain fixes (see the URL above) we can help multiple callers not tear out session from one another, or be needlessly blocked by one another. Some of these things may be possible within 2.40, and others may be longer term. Cheers, Stef 1. Counted Initialize/Finalize This is a longer term component, and may not be material for 2.40, pending discussion. Proposing that C_Initialize may be called multiple times within a process without returning CKR_CRYPTOKI_ALREADY_INITIALIZED.
In the Solaris provided libraries and applications that call C_Initalize() we check for CKR_OK and CKR_CRYPTOKI_ALREADY_INITIALIZED and treat both as success.
C_Finalize must be called the same number of times before actually finalizing the token. Corollary is that C_Initialize and C_Finalize implementations must be thread safe.
We actually had that implemented for our Solaris libpkcs11 many years ago, but we removed it before we integrated into Solaris 10 and shipped. The reason we removed it is that it wasn't compliant with the spec.
I'd like to see this formalised as being the correct thing to do.
2. C_CloseAllSessions clarifications Clarify that C_CloseAllSessions should contain language which states that it should not be called gratuitously, since it will cause other (perhaps unrelated callers) of the token in the same process to fail. Callers of sessions should be aware that their sessions should be closed at any time, and should recover gracefully from this.
Agreed.
3. No assumptions about state after C_CloseSession and C_CloseAllSessions Callers should not make assumptions about the login state of a token after C_CloseSession or C_CloseAllSessions has been called, and be ready for either logged-in or logged-out state. Another caller may log in or have another session open which affects the login state.
Agreed.
4. CKU_SO + read only sessions Generic code which implements PKCS#11 enumeration (or related) patterns/algorithms, is complicated by the fact that they cannot rely on opening a read-only session. (eg: display or listing algorithms). These algorithms have to test the login state of the token in order to know whether they can open a read-only session, or whether the user is CKU_SO (in an inherently racy manner). We should remove the restriction of using read-only sessions together with CKU_SO.
That makes sense to me. -- Darren J Moffat
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]