Re: gnome-keyring p11-unity [was: Re: Multiple libraries using PKCS#11 modules and CKR_ALREADY_INITIALIZED]

[Stef Walter <stefw collabora co uk>]

On 01/22/2011 10:06 AM, Joe Orton wrote:
> On Fri, Jan 21, 2011 at 04:10:50PM -0600, Stef Walter wrote:
>> So to summarize by using something like p11-unity we would get:
>>
>>  * Solve the refcount initialization problem when multiple PKCS#11
>>    consumers in a process want to use the same PKCS#11 module.
>>  * Drop in usage with current PKCS#11 consumers, like NSS.
>>  * Single implementation of PKCS#11 system configuration.
>>  * Can expose more powerful library functions for accessing details
>>    about a module's config (eg: algorithm selection)
> 
> That looks like a good solution to that problem set; I think you'd have 
> to also address the forking problem as Nikos has patched into pakchois 
> (sorry I still need to merge those, Nikos).

Yes, good. We'd want to include that too.

I've done more work today on the library functions in p11-unity. Some of
the functions work on the registered functions, and others work on
arbitrary modules that consumers wish to initialize.

http://thewalter.net/git/cgit.cgi/p11-unity/tree/module/p11-unity.h

Not yet tested properly.

I haven't yet worked on the configuration stuff. I haven't had time, so
p11-unity still just enumerates /usr/lib/pkcs11 for registered modules.

Joe, what would it take to make p11-unity (or something like it) a
dependency of pakchois?

I've been wondering if perhaps 'p11-unity' is a bit pretentious of a
name. Maybe 'p11-kit' would be better?

> a) to serialize access to (hardware) resources sensibly. In my testing 
> PKCS#11 modules tend to fail rather than block when you attempt to use 
> the hardware concurrently from different processes, and there are also 
> issues w.r.t. long-lived sessions.  There was a thread on moz-crypto 
> just recently about Firefox & PKCS#11 locking, perhaps related:

Yes, that's true. I guess there are two ways to fix this problem:

 a) As PKCS#11 becomes more ubiquitous in Linux, the modules will need
    to improve their quality.

 b) Load low quality modules into a daemon. But that daemon would need
    to fork N processes for N clients, and then synchronize between
    these forked daemon processes.

> But I haven't investigated this stuff thoroughly or even recently, 
> probably these problems can be solved separately if that proves 
> necessary, and I should stop heckling you from the peanut gallery ;)

Not at all. These are important things to bring up. Looking forward to
more of your heckling :)

Cheers,

Stef