[Opendnssec-develop] Thread safety

Rickard Bondesson Rickard.Bondesson at iis.se
Wed Dec 3 12:18:39 UTC 2008


-----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-----



More information about the Opendnssec-develop mailing list