On Wed, Apr 16, 2008 at 3:10 PM, Jennings Jared L CTR USAF 46 SK/CCI <jared.jennings.ctr@xxxxxxxxxxxx> wrote: > I saw guidance on the Subversion users mailing list > <http://svn.haxx.se/users/archive-2008-03/1004.shtml> about Subversion > with PKCS#11. Accordingly, I compiled pakchois 0.4, GNU TLS 2.3.5, and > neon 0.28.2 (with pakchois), compiled Subversion HEAD (r30607) using > them, put directives in my subversion configuration file as directed to > point it at CoolKey, and got the following error, immediately, upon > trying to use my shiny new smartcard layer: > > subversion/libsvn_ra_neon/session.c:1212: (apr_err=175006) > svn: Invalid config: unable to load PKCS#11 provider 'coolkey' > > Digging deeper with gdb, I found out that coolkey's C_Initialize was > returning 10 [== (ck_rv_t_) CKR_CANT_LOCK]. Looking in the PKCS#11 spec > <ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf> , I > found (p. 119 of the PDF, p. 103 if you print it) that the parameters > passed to C_Initialize signified that coolkey "needs to use the native > operating system [threading] primitives to ensure safe multi-threaded > access. If the library is unable to do this, C_Initialize should return > with the value CKR_CANT_LOCK." > > Relevant snippet from pakchois.c (around line 212): > > /* Require OS locking, the only sane option. */ > memset(&args, 0, sizeof args); > args.flags = CKF_OS_LOCKING_OK; > args.reserved = reserved; > > rv = fns->C_Initialize(&args); > if (rv != CKR_OK) { > goto fail_ctx; > } > > Contrast coolkey.cpp, lines 223-225: > > if( (initArgs->flags & CKF_OS_LOCKING_OK) || initArgs->LockMutex > ){ > throw PKCS11Exception(CKR_CANT_LOCK); > } > > How can pakchois be used with coolkey if pakchois expects coolkey to do > this OS_LOCKING thing and coolkey drops OS_LOCKING like a hot rock? This is a known issue. Coolkey itself doesn't do locking. The caller is expected to lock around its calls to coolkey. PKCS #11 allows such thread-unsafe Cryptoki libraries, and NSS can handle them just fine, which is why coolkey was written this way. Coolkey should be made thread-safe and we can start by adding a coarse big lock that is acquired on entry to every coolkey C_xxx method, and released on exit. This emulates what NSS does for thread-unsafe Cryptoki libraries. We need to make sure no C_xxx method calls another C_yyy method, otherwise we would have a deadlock with the big lock approach. Your investigation of this problem shows that you are very comfortable with compiling and debugging coolkey. Would you be interested in taking a stab at this? Wan-Teh _______________________________________________ Coolkey-devel mailing list Coolkey-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/coolkey-devel
