On Tue, 2 Mar 2010, Vladimir Kotal wrote:
>> I should have said before: I am using the patch. Right now I am testing on
>> Solaris 10 (not OpenSolaris), but it will eventually be used on Linux, I
>> think.
>
> Using custom OpenSSL libraries on (Open)Solaris is definitely not supported by
> Sun/Oracle so I will only respond to generic issues.
>
> As for the support of the patch itself I will let Jan to answer this one.
we do not support the patch. We gave it out in hope it would be
useful but with no intent to support it.
>>> PKCS#11 engine does not supply its own primitives, that's all.
>>>
>>
>> It doesn't work with the HSM in question. And as far as the spec goes,
>> not passing NULL_PTR is equivalent to saying "I am not going to call this
>> from
>> multiple threads". The PKCS#11 library detects this and returns an error. If
>> the
>> engine is not specifying its own primitives, it should at least set
>> CKF_OS_LOCKING_OK in CK_C_INITIALIZE_ARGS.
>
> In Solaris Crypto Framework, supplying pInitArgs set to NULL_PTR to
> C_Initialize() means to use internal locking primitives.
>
> See the following:
> http://docs.sun.com/app/docs/doc/816-4863/chapter2-9d?a=view
>
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/pkcs11/libpkcs11/common/pkcs11General.c#C_Initialize
>
> In overall, I think it's nothing against nothing :) By supplying NULL_PTR the
> app says it does not care about threads but by linking against SCF libraries
> it
> knows the threading will be handled well via internal functions so there is no
> need to supply its own locking functions.
I agree. CK_C_INITIALIZE_ARGS are optional and by not providing
them we just say nothing about threads. And since we know that the CF is
thread safe, it's OK for us. It's good to note that the patch was
generated using code from OpenSolaris, no other changes were made.
I should probably put a note to README.pkcs11 about this if
there is going to be a new version.
>> Well, destroying the private key is hardly the way to prevent memory leaks.
>> If, say, it were a smart card, with keys generated on the card, calling
>> C_DestroyObject will the destroy the only copy of the key on the card. And
>> that
>> is not good...
>
> But for non-token objects it does matter very much :) The key-by-ref project
> addresses this issue.
exactly.
J.
--
Jan Pechanec
http://blogs.sun.com/janp
