RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v2]

[Martin Balao]

On Thu, 7 Jan 2021 21:00:58 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> I chose the term 'leak' in the sense of a resource not properly cleaned up. In this case, the 'leak' would not cause a memory/sockets/file-descriptors but a 'usable-sessions' exhaustion. It's always an analogy, but the sense is that something (a Session) unexpectedly (with an active operation) passes from one side (a P11Cipher instance) to another (the Session Manager). I don't believe 'corruptor' describes the concept better than 'leaker'. The Session is not corrupt, it can be used for for a specific purpose (the same operation that previously failed). Any other suggestion? Hmm... I cannot think of something better.
>
> So, after this PKCS11 session failed with an error, you can continue using it, say give it another byte[] and it would continue to work as if the earlier failed call never happened? I have not really tried it and thought that this session is unusable due to the combination of an existing error (say some exception happened during the encrypt update call) and active operation state.

Yes, that's right: you can use the session to continue the same operation. In fact, there is a pattern -also used in some Windows API functions- that you send an output buffer of length 0, you get a CKR_BUFFER_TOO_SMALL error and the buffer size that would have been required; and you make a second call with the right buffer size. This pattern is used from the OpenJDK native library that communicates with the PKCS#11 lib. Some types of errors (those that do not free the context) are not fatal. The problem is that we end up returning a session to the Session Manager and we try to use the session to initialize a different operation, while the previous is still active.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1901