Re: pakchois + CoolKey

["Wan-Teh Chang" <wtchang@xxxxxxxxx>]

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