JDK-8240256 : Better resource cleaning for SunPKCS11 Provider
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto:pkcs11
  • Affected Version: 8u231
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-02-29
  • Updated: 2021-10-09
  • Resolved: 2021-06-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 8
11.0.12.0.3-oracleFixed 8u311Fixed
Related Reports
CSR :  
Relates :  
Relates :  
Sub Tasks
JDK-8272907 :  
JDK-8273024 :  
Description
Submitter complaining that Sessions seen left on heap after numerous SunPKCS11 providers and initialized and logged out from.

# jcmd 170515 GC.class_histogram | grep pkcs11.Sess
 558:            35           1680  sun.security.pkcs11.SessionManager
 559:            70           1680  sun.security.pkcs11.SessionManager$Pool
 614:            35           1400  sun.security.pkcs11.Session
 615:            35           1400  sun.security.pkcs11.SessionRef
# jcmd 170515 GC.class_histogram | grep pkcs11.Sess
 535:            38           1824  sun.security.pkcs11.SessionManager
 536:            76           1824  sun.security.pkcs11.SessionManager$Pool
 585:            38           1520  sun.security.pkcs11.Session
 586:            38           1520  sun.security.pkcs11.SessionRef
Comments
Fix Request (11u): Should get backported for parity with 11.0.14-oracle. Actual fix applies cleanly, but the tests need resolution. Review: https://github.com/openjdk/jdk11u-dev/pull/352
15-09-2021

Changeset: bdeaeb47 Author: Sean Coffey <coffeys@openjdk.org> Date: 2021-06-03 06:45:06 +0000 URL: https://git.openjdk.java.net/jdk/commit/bdeaeb47d0155b9f233274cff90334e8dd761aae
03-06-2021

Work is still progressing on this issue. I'm attempting various framework edits to clean up the small number of pool sessions that are idling but it's a complex scenario. Examples: 1. Sessions have to be routinely created to determine the status of the pkcs11 Token insert/remove operations. In current design, the pool sessions can be used. (via TokenPoller) 2. Also, Sessions operate a referent list design whereby any keys/artifacts from a pkcs11 derived operation prevent the Session from being "released". I was hoping to hear from the submitter as to why a re-design is required here. It turns out to be a very conscious design effort to have a maximum of 10 idling Sessions per PKCS11 Provider. *IS* the submitter creating multiple SunPKCS11 Providers in production code or is this for a test demo purposes only?
10-04-2020

An update on current status. To summarize, each SunPKCS11 Provider has a SessionManager to control PKCS11 sessions. These sessions are grouped into two pools per Provider, one for holding object sessions and one for holding operation sessions. The sessions are pooled in order to minimize the number of C_OpenSession() and C_CloseSession() that have to be made. A small number of idling sessions are left in each pool (5 per pool) - This would be a maximum of 10 idling sessions plus working sessions per SunPKCS11 Provider. It most likely explains what the Cu is seeing. I'm reviewing the design to see if we can have some sort of logout mechanism which destroys all sessions in the pool. It would be less efficient but appears to be a use case that Cu is looking for. If they keep SunPKCS11 use to one instance (most common), they should only have a maximum of 10 sessions left in the JVM pool.
10-04-2020