Future plans about nethsm-pkcs11

[jans23]

Regarding 2: Note that we use openapi generation for other implementations too (e.g. pynitrokey but also recommend it to users directly). Hence, a solution which is not limited to this pkcs11 module would be preferred,

[nponsard]

Regarding 2: Note that we use openapi generation for other implementations too (e.g. pynitrokey but also recommend it to users directly). Hence, a solution which is not limited to this pkcs11 module would be preferred,

The problem comes from the generator that is language-specific, so it wouldn't help with the python version for example.

[ansiwen]

Ad 1) Could we use a deterministisc keyhandle generated from the key-id? If not, I think we could make the key-handle->key-id mapping global, in a structure that is initialized when the module is loaded. (So not per session but per module lifetime.)

[ansiwen]

Ad 2) the generator allows templating to customize the generated code.

[ansiwen]

Ad 3) the calls are always "blocking", they cannot yield. But PKCS11 has a feature that allows to call the functions concurrently from several threads. So, in order to support that feature, we would need to synchronize access to all data, that is mutable and shared between calls, like session data and so on. Best is of course to minimize mutable data.

[nponsard]

Ad 3) the calls are always "blocking", they cannot yield. But PKCS11 has a feature that allows to call the functions concurrently from several threads. So, in order to support that feature, we would need to synchronize access to all data, that is mutable and shared between calls, like session data and so on. Best is of course to minimize mutable data.

I think Rust imposes a thread-safe behavior so this could already work then.

[ansiwen]

Ad 3)

A consequence of the fact that a single session can, in general, perform only one operation at a time is that an application should never make multiple simultaneous function calls to Cryptoki which use a common session. If multiple threads of an application attempt to use a common session concurrently in this fashion, Cryptoki does not define what happens. This means that if multiple threads of an application all need to use Cryptoki to access a particular token, it might be appropriate for each thread to have its own session with the token, unless the application can ensure by some other means (e.g., by some locking mechanism) that no sessions are ever used by multiple threads simultaneously. This is true regardless of whether or not the Cryptoki library was initialized in a fashion which permits safe multi-threaded access to it. Even if it is safe to access the library from multiple threads simultaneously, it is still not necessarily safe to use a particular session from multiple threads simultaneously.

See here.

So session data does not have to be synchronized. Concurrent threads need to open separate sessions anyway.

[ansiwen]

I think Rust imposes a thread-safe behavior so this could already work then.

I doubt this is true in this scenario, because the application that calls the functions is out of reach of the Rust compiler. If I call a function, that is implemented in Rust, from two concurrent threads, and that Rust implementation has mutable data, there will be a race condition. (The borrow checker can't see that race.)

[nponsard]

The tool I'm using to have data shared between function calls, lazy_static refuses to have shared mutable data that isn't protected by a mutex.

[ansiwen]

The tool I'm using to have data shared between function calls, lazy_static refuses to have shared mutable data that isn't protected by a mutex.

And that tool supports calls from non-rust calls? So it in general does not allow shared data between functions calls? (So I guess it's a kind of reentrant safety checker?)

[ansiwen]

And anyway, as I wrote befor: if the mutable data is all within the session data, we are safe anyway, because sessions are single-thread only.

[nponsard]

I've got shared data to link the key handles to key ids, but it's behind a mutex