[Opendnssec-develop] Thread safety

[Roland van Rijswijk]

Hi Rickard,

It is up to an application that uses a PKCS #11 module to specify which 
threading model it uses. Section 6.6.2 specifies which options there 
are, I'll summarise here:

1. No multithreading
2. Multithreading using OS primitives
3. Multithreading using application supplied primitives
4. Multithreading using either OS primitives or app-supplied primitives

If the application indicates that "OS locking is OK", then that means 
that the PKCS #11 module must make sure that any calls to it are thread 
safe by protecting access to shared resources using standard OS calls 
for locking. So that means you have to implement locking behaviour. The 
best way to do this is to create an abstract interface for locking which 
either calls OS locking services or application supplied services based 
on the settings supplied in the call to C_Initialize or performs no 
locking at all if C_Initialize was called with a NULL_PTR parameter.

Does that help?

Cheers,

Roland.

Rickard Bondesson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> One comment in hsm-speed.c says:
> 
> // Initialize Library
> // Note that we do not need mutex locking for thread safety,
> // since we're using one session per thread.
> 
> But PKCS11 says:
> 
> "A call to C_Initialize with pInitArgs set to NULL_PTR is treated like a call to
> C_Initialize with pInitArgs pointing to a CK_C_INITIALIZE_ARGS which has the
> CreateMutex, DestroyMutex, LockMutex, UnlockMutex, and pReserved fields set to
> NULL_PTR, and has the flags field set to 0."
> 
> And
> 
> "1. If the flag isn’t set, and the function pointer fields aren’t supplied (i.e., they all have
> the value NULL_PTR), that means that the application won’t be accessing the
> Cryptoki library from multiple threads simultaneously."
> 
> This means that the HSM will not create any locking mechanisms for its crucial components like its object store, which in my case are shared between the sessions.
> 
> My SoftHSM will because of this fail, when the hsm-speed.c runs multiple threads, due to multiple accesses to a single object. (The failure is in the crypto lib when it accesses its key objects. The lib is thread safe but not for a single object.)
> 
> Which is the appropriate action? Should I, as a HSM, create locks although the external application did not want me to do that? Or should the hsm-speed.c be modified so that it either provides mutex functions or tell the HSM to use its own mutex functions.
> 
> // Rickard
> -----BEGIN PGP SIGNATURE-----
> Version: 9.8.3 (Build 4028)
> Charset: utf-8
> 
> wsBVAwUBSTZ5H+CjgaNTdVjaAQgttgf/a+ePbBbnsOqp88qOoG6wjl28ta3LoJoc
> qesDBhDQfC8tjCOvbRj1ey7C5J5slzQYLCxlfR24ob/QZL7jjwHgXw74dwEDHSUC
> 5w2RrnoJefKdWkCcSCnWWlrEE9KP30TRH7rbIMf41w+t+jsFx12ywKLYx1rfzzoe
> hcwPJUMUIyxsQLdv1BNkUlbc6FRHwatMY8TXM1TnUUMMyNohwxwz1LM8nmzXl/kw
> wyz82Blj9lbPTuAM+3SQ+yXpUcVKR6dRveq1azOE3t5g7CPLAFB8hFaVjdKtMWpW
> JCQ3ZAIKmQLckMy54xvg2Ha8pbheXyvNpgy2D0CvqAE5cELb+y/C6w==
> =44rA
> -----END PGP SIGNATURE-----
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop


-- 
-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl