JDK-7036252 : sunpkcs11-solaris.cfg needs a review
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto:pkcs11
  • Affected Version: solaris_11
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris
  • CPU: generic
  • Submitted: 2011-04-13
  • Updated: 2014-03-18
  • Resolved: 2011-06-22
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 7
7 b142Fixed
Related Reports
Relates :  
JDK-8037742 - Re-enabling PKCS11 HMAC mechanisms in Solaris
Description
The default sunpkcs11-solaris.cfg configuration file has far too much stuff disabled for
current releases of Solaris and current SPARC hardware.

All of the bugs listed in that file have been fixed.  More importantly the performance
assumptions that were valid at the time this file was created no longer apply.
Comments
EVALUATION Release note wording suggestion: Given the relevant Solaris bug (i.e. 6306708 "CKM_SSL3_KEY_AND_MAC_DERIVE returns incorrect cipher keys for exportable ciphersuites") has been addressed in solaris 10 update 5 release, SunPKCS11 provider no longer disables the following two mechanisms by default: CKM_SSL3_KEY_AND_MAC_DERIVE CKM_TLS_KEY_AND_MAC_DERIVE
23-05-2011
EVALUATION Since 6306708 has been fixed in both snv_26 and s10u5, and also that no failures when running against existing regression tests, we'll remove CKM_SSL3_KEY_AND_MAC_DERIVE and CKM_TLS_KEY_AND_MAC_DERIVE from the disabledMechanisms section.
29-04-2011
EVALUATION I ran my own simple test program (SigTest.java) for measuring the difference in Signature verification. When I ran on T4, I didn't observe much difference between the two different configuration files (i.e. the default one vs. the one enabling the CKM_[MD]_RSA_PKCS mechanisms by default). Note that even though we disable CKM_[MD]_RSA_PKCS mechanisms by default, SunPKCS11 provider will attempt to use CKM_RSA_PKCS (or CKM_RSA_X_509) as long as either is supported. In the case of T4, both CKM_[MD]_RSA_PKCS and CKM_RSA_PKCS are accelerated, so using one or the other doesn't make much difference (at least for my simple test program).
28-04-2011
EVALUATION Perhaps a consideration here is to have the JDK/JRE installer update the sunpkcs11-solaris.cfg file at installation time based on the detected hardware where the JDK/JRE is installed? Alternatively, perhaps the JVM can use a specific sunpkcs11-solaris.cfg depending on the hardware platform detected by the JVM at JVM initialization time. The JVM already has logic to detect the underlying platform for (JIT) compiler optimizations. Perhaps the same mechanism can be used to load a specific sunpkcs11-solaris.cfg file for specific platforms?
28-04-2011
EVALUATION This is all very very different for SPARC T4 where all the crypto comes from pkcs11_softtoken and both CKM_RSA_PKCS and the CKM_[MessageDigest]_RSA_PKCS mechanisms are accelerated. The fundamental issue here is that there is one config file that is shipping with lots of stuff disabled regardless of the underlying architectures capabilities in hardware acceleration. For SPARC T4/M4 that means Java is missing out on a lot of potential performance gain.
28-04-2011
EVALUATION Well, besides performance, we need to ensure that enabling these previously disabled mechanisms won't lead to regressions or failures. After further experiment, we can't enable the 6 message digest mechanisms since JSSE relies on message digest cloning functionality during its handshakes. Need to address 6414899 "P11Digest should support cloning" first before attempting to enable the message digests by default. Then, as for the mechanisms CKM_DES_CBC_PAD, CKM_DES3_CBC_PAD, and CKM_AES_CBC_PAD, enabling them doesn't make much difference performance-wise. The reason is that SunPKCS11 provider uses their no padding counterpart and perform the necessary padding before/after calling the native library. Considering that 6545046 "pkcs11_softtoken doesn't properly strip pkcs7 padding" is only fixed in Nevada and not in S10 updates, it's not worthwhile to enable the above 3 mechanisms by default. As for the 6 mechanisms for signature, i.e. CKM_DSA_SHA1, CKM_[MD5, SHA1, SHA256, SHA384, SHA512]_RSA_PKCS, enabling them actually hurts performance when the system has a hardware crypto accelerator card which supports CKM_RSA_PKCS but not the CKM_[MessageDigest]_RSA_PKCS mechanism. When using Solaris softtoken impl, it's several times slower than the pure java provider. Need to check w/ the performance team to see if they have further input on this.
27-04-2011