On 10/20/2009 02:56 AM, David Smith wrote: > On Tue, Oct 20, 2009 at 6:47 PM, Alon Bar-Lev <[email protected]> wrote: > >> Oh... I really don't know libp11... >> But if one process called C_Initialize() and then another/same thread >> called C_Initialize() again and calls C_Finalize, first thread will >> not be able to continue working. >> >> > That could be an acceptable failure scenario in the libp11 case > because it doesn't seem like it's meant to be thread safe (it's > supposed to be a simplification layer...) At any rate, the libp11 devs > should fill us in how they want it to be handled. > > As PKCS #11 is defined, it's not generally safe to ignore CKR_ALREADY_INITIALIZED.
If multiple different libraries try to load the same PKCS #11 module, there are some points of potential conflict between the different uses. First, as Alon pointed out, there's the C_Finalize issue. When either library finalizes, the other library is out in the cold (loosing all his session objects and sessions and not able to complete new PKCS #11 operations on the token). Second, some tokens are not thread safe. That means there needs to be a common lock, but neither library knows about the other, so they will have their own lock. Certain PKCS #11 calls can effect global state (C_Login, C_Logout, etc.). This shouldn't be a huge problem as applications that use PKCS #11 should expect these states to change out from under it as a result of token insertions and removals. So... if you know that you are doing 'cooperative sharing' of PKCS #11 modules, and that all libraries using the PKCS #11 modules agree, then If you never call finalize, and do not try to share non-thread safe tokens, then you may be able to ignore CKR_ALREADY_INITIALIZED, otherwise you cannot necessarily assume that the library was initialized by another version of libp11 (caveat -- if libp11 remembers what modules it had already opened, then it could check on a CKR_ALREADY_INITIALIZED error and see if it was the one that opened the module. In that case it could safely handle CKR_ALREADY_INITIALIZED). This issue is probably going to get more prevelant, so it may be worth talking with the cryptoki working group about handling this situation more cleanly in 3.0. bob
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
