OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [pkcs11] Fwd: Re: [pkcs11-comment] PKCS#11 Usage Guide vs. POSIX issue

On 05/11/15 23:09, Tim Hudson wrote:
FYI - David's response ...

We do use pthread_atfork() in the Solaris delivered PKCS#11 libraries and it has been hard to get it properly implemented. We have that added complexity that we have PKCS#11 plugged into PKCS#11 and the fact we use PKCS#11 in other libraries.

All of our libraries would actually have worked just fine in the child and the parent of the fork() but we have had to add code to break that. This is particularly difficult to deal with then PKCS#11 is several layers of library and plugin below the application that called fork().

The standard should be updated to remove the whole requirement to C_Finalize() in the child of fork() - PKCS#11 should not specify anything about fork other than it should be fork safe (ie the child can continue to use the handles). It makes PKCS#11 unlike any other crypto library and makes it very difficult to use - it has been the cause of some very serious and hard to debug problems for us. Especially when PKCS#11 is actually plugged in underneath another crypto API (OpenSSL via ENGINE or JCE via JNI calls to PKCS#11).

When you fork() in UNIX you *are* still running with the same credentials so there really is no reason to invalidate the connection to the PKCS#11 "subsystem". The time when you potentially want to invalid is on exec() or maybe on setreuid() calls, not on fork(). If the PKCS#11 library uses a file descriptor as the "connection" to some backend that authenticated the user at C_Login() then you can set the fd to be closed on exec. If you really think you need to deal with setreuid() calls then you are a) probably wrong and going to break legitimate uses or b) you are part of the OS and have other potential hooks available to you, but even then see a).

Darren J Moffat

-------- Original Message --------
Subject: 	Re: [pkcs11-comment] PKCS#11 Usage Guide vs. POSIX issue
Date: 	Mon, 11 May 2015 21:03:51 +0000
From: 	Woodhouse, David <david.woodhouse@intel.com>
To: 	tjh@cryptsoft.com <tjh@cryptsoft.com>
CC: 	pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org>

On Tue, 2015-05-12 at 06:50 +1000, Tim Hudson wrote:
David, it appears to my reading of your email at least - that all of
the issues you are raising are related to implementation issues with
specific vendors and/or some vendors use of pthread_atfork ... and
not with the specification itself.

Yes, in a sense that's true.

But it seems like using pthread_atfork() is one of the only obvious
ways to implement the "good Cryptoki programming practice" of calling
C_Initialize() whenever the application forks.

We don't spell it out, but we are *leading* the developer to use
pthread_atfork(). I'm not quite sure how else one would implement the
recommendation and expect it to cover fork() from arbitrary library
routines, etc.

Given that the obvious implementation of what we recommend is a clear
violation of the POSIX specification when we do it from a multi
-threaded process, surely it warrants at least a *caveat* that perhaps
the reader might want to bear the POSIX requirements in mind?

Sure, we are *only* leading them to the cliff, and we didn't make them
jump. But maybe we could point it out to them?

Darren J Moffat

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]