p11_kit_initialize_registered in a constructor

Stef Walter stef-list at thewalter.net
Wed Dec 4 22:25:29 PST 2013

On 04.12.2013 08:34, Nikos Mavrogiannopoulos wrote:
> On Sun, 2013-12-01 at 16:29 +0100, Stef Walter wrote:
>> On 30.11.2013 16:27, Nikos Mavrogiannopoulos wrote:
>>> Hello,
>>>  Would using p11_kit_initialize_registered() in a library constructor
>>> work? I can think of issues with error reporting, but I cannot think of
>>> anything that would inherently prevent that, or am I wrong?
>> If loading other libraries (including those that might in turn link in a
>> library constructor) from a library constructor is okay, then I would
>> imagine it's fine.
>> On the other hand, the behavior of C_Initialize for various PKCS#11
>> modules is far from well-behaved. Some of them take many tens of seconds
>> to complete.
>> I would suggest using the new p11-kit API, and loading the modules, but
>> not initializing them until use.
> I guess you mean splitting p11_kit_modules_load_and_initialize() to
> p11_kit_modules_load() and p11_kit_modules_initialize() (btw. these
> functions are not in the API index of the web-site manual). 



> That requires quite some changes, and safe guarding with locks to work,
> but looks certainly doable.

By default (unless P11_KIT_MODULE_UNMANAGED was set as a module flag),
p11_kit_modules_initialize() can be called multiple times and
concurrently, and does appropriate locking.

Ditto for p11_kit_modules_load().

Just make sure you call p11_kit_modules_finalize() and
p11_kit_modules_release() the same amount of times, respectively.

This makes PKCS#11 use less of a global thing, BTW, which may be a win
for GnuTLS. GnuTLS could have a list of PKCS#11 module pointers per
session or context or whatever makes sense.

There's no major performance penalty to doing this, p11-kit
appropriately loads modules once, and refs them after that, same for



More information about the p11-glue mailing list