Cherry-Pick -- Always Finalize the PKCS11 FindObject Operation #1978
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There are 6 pkcs11 operations that require the session
handle to be finalized before a session can be reused.
These operations are: Encrypt, Decrypt, Sign, Verify,
Find, and Digest. The bccsp/pkcs11 package makes use
of three of these operations: sign, verify, and find.
Each of these operations has an init function, i.e.,
SignInit, VerifyInit and FindObjectInit, each are part
of the cryptoki implementation. If the Init functions
fail, the session handle is never initialized and
the finalize function do not need to be called.
For SignInit and VerifyInit, the next operation
we call are the Sign or Verify functions, which also
atomically finalized the session. For the FindObjectInit
operation however, we must explicitly call the FindObjectFinal
function to release the lock on the session handle.
The current implementation makes a call to FindObject in between
FindObjectInit and FindObjectFinal which has an error path.
In the current implementation FindObjectFinal is not called
on the error path, leaving the session in a state that it can't
be used again.
This change ensures FindObjectFinal is always called, even
on the error path.
Signed-off-by: Brett Logan [email protected]