IBM SDK, Java Technology Edition, V6 (J9 VM2.6): Current news

Content

The documentation to support IBM SDK, Java Technology Edition, Version 6 (J9 VM2.6) is available in the product documentation . Supplementary information is available in this support document.

Note: Support for IBM SDK, Java™ Technology Edition, Version 6 (J9 VM2.6) has ended for all platforms unless covered by an extended support contract or embedded in an IBM product that has not reached its own end of service date. End of service dates for the IBM SDK are shown in the JavaSDK developer center . End of service dates for all IBM software products are listed here .

More information on large page requirements for Linux

This information is supplementary to the "Configuring large page memory allocation" topic in the IBM Knowledge Center.

The JVM depends on the SYSV shared memory system calls shmget and shmat. If a request to allocate a large page failed, ensure that the values of the kernel parameters SHMMAX and SHMALL are sufficient for your operating system to allocate large pages.

SHMMAX: The maximum size of a shared memory segment, in bytes.
SHMALL: The total amount of shared memory in the system, in either bytes or pages.

PKCS11 security provider

The following card is supported in a limited fashion on the AIX® platform, in both 32-bit and 64-bit modes:

• The IBM 4765 PCIe Cryptographic Coprocessor is supported for use only by Tivoli Key Lifecycle Manager (TKLM) release 2.0.1, and follow-on releases.

Note: For TKLM, only the following PKCS#11 crypto operations are supported:

• • Translate an AES 128-bit or 256-bit software key to an AES hardware (PKCS#11) key
  • Generate an AES 128-bit or 256-bit key
  • Encrypt and decrypt data using an AES key and an AES/ECB/NoPadding cipher
  • Store and retrieve an AES key to/from a PKCS11IMPLKS (PKCS#11) key store











 

See additional supplementary information that is available for the following release levels:

• Service refresh 8 fix pack 60
• Service refresh 8 fix pack 50
• Service refresh 8 fix pack 45
• Service refresh 8 fix pack 41
• Service refresh 8 fix pack 7
• Service refresh 8 fix pack 3
• Service refresh 6
• Service refresh 5 fix pack 2
• Service refresh 5 fix pack 1
• Service refresh 5
• Service refresh 2

To compare the IBM SDK functionality with Oracle build levels at each service refresh level, see Comparative Oracle build levels .

For information about security fixes, see Security Alerts .
For information about IBM fixes, see IBM SDK, Java Technology Edition, Version 6.1 fixes .

For information about the daylight saving time changes included in service refreshes and fix pack levels, see Olson time zone updates . Later updates can by applied using the IBM Time Zone Update Utility for Java (JTZU) .

Service refresh 8 fix pack 60 (Jan 2018)

Security changes

The following changes are made to security as a result of the Oracle Critical Patch Update (CPU):

• Unlimited jurisdiction policy files are now used by default
• Stricter key generation
• IBMJCE provider default Diffie-Hellman (DH) key size change
• IBMPKCS11Impl provider default key size changes
• IBMJCE provider RSA public key validation
• Exportable cipher suites disabled by default
• Jar files can no longer be signed with DSA key sizes less than 1024 bits

To learn more about these changes, see the "What's new" topic in the Java 6 security guide for service refresh 16 fix pack 60.

Out of memory exceptions when running applications with compressed references enabled

The Oracle CPU for January contains an update for CVE-2018-2582 to fix vulnerabilities in the Hotspot virtual machine (VM) that might be exploited by Java web start applications and applets. Fixes are also applied for the OpenJ9 virtual machine. The fix increases the amount of low memory used for VMs that use compressed references. Customers who are running close to the maximum amount of allowed 32-bit memory might experience out of memory exceptions. A possible workaround is to use the -Xmcrs option to secure space in the lowest 4GB memory area for any native classes, monitors, and threads that are used by compressed references.

For more information about this option, see the " - Xcmrs" topic in the product documentation.

Security checking

To improve security, the security checks in the following APIs are now enabled by default, when the SecurityManger is enabled:

• com.ibm.jvm.Dump.JavaDump()
• com.ibm.jvm.Dump.HeapDump()
• com.ibm.jvm.Dump.SystemDump()
• com.ibm.jvm.Dump.SnapDump()

• com.ibm.jvm.Log.QueryOptions()
• com.ibm.jvm.Log.SetOptions(String)

• com.ibm.jvm.Trace.set(String)
• com.ibm.jvm.Trace.snap()
• com.ibm.jvm.Trace.suspend()
• com.ibm.jvm.Trace.suspendThis()
• com.ibm.jvm.Trace.resume()
• com.ibm.jvm.Trace.resumeThis()
• com.ibm.jvm.Trace.registerApplication(String, String[])
• com.ibm.jvm.Trace.trace(<any parameters>)

You can disable security checking for these APIs by setting the following system properties on the command line:

• -Dcom.ibm.jvm.enableLegacyTraceSecurity=false
• -Dcom.ibm.jvm.enableLegacyDumpSecurity=false
• -Dcom.ibm.jvm.enableLegacyLogSecurity=false

Service refresh 8 fix pack 50 (July 2017)

IBMPKCS11Impl RSA cipher support for OAEP padding

The IBMPKCS11Impl provider now supports Optimal Asymmetric Encryption Padding (OAEP padding) for the RSA cipher on the following platforms:

• 32-bit and 64-bit AIX®
• 32-bit and 64-bit Linux on x86
• 32-bit and 64-bit Windows

For more information, see "Appendix A: Supported Algorithms" in the IBM SDK, Java Technology Edition, Version 6 Security guide.

IBMPKCS11Impl Elliptic Curve Diffie Hellman (ECDH) Key Agreement algorithm support for key derivation functions with sharedInfo

The ECDH KeyAgreement algorithm is enhanced to support key derivation functions (KDF) with sharedInfo. For more information, see "Appendix A: Supported Algorithms" in the IBM SDK, Java Technology Edition, Version 6 Security guide.

A new class, com.ibm.crypto.pkcs11impl.provider.KDFParameterSpec, is available to initialize the ECDH KeyAgreement object with a KDF value and sharedInfo. For more information about the class, see the "PKCS 11 Implementation Provider" API section in the product documentation.

Support for a new PKCS11# mechanism, CKM_ECDH1_COFACTOR_DERIVE, is also included. To learn how to programmatically invoke the CKM_ECDH1_DERIVE and CKM_ECDH1_COFACTOR_DERIVE hardware mechanisms, see the "PKCS11 Usage Tip #5" topic in the product documentation.

Go back to top

Service refresh 8 fix pack 45 (April 2017)

Jar files signed with MD5 are treated as unsigned

To improve security, a new restriction is introduced in this refresh as part of the Oracle Critical Patch Update (CPU). Applications, including Applets or Web Start applications that use jar files that are signed with MD5 are affected. These jar files are treated as unsigned. To address the issue, the jar file must be re-signed with a stronger algorithm or key size. For more information about this change, which includes a short term workaround, see the Oracle JRE and JDK Cryptographic roadmap .

EC with keys less than 224 bits are disabled

The following two properties are updated to prevent the use of EC keys with less than 224 bits:


jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, 3DES_EDE_CBC, EC keySize < 224

EC curves weaker than 256 bits are removed from the default enabled list

The following list shows curves that are enabled by default:


 // recommended
   secp256r1 (23)
   secp384r1 (24)
   secp521r1 (25)

   // NIST curves
   sect283k1 (9)
   sect283r1 (10)
   sect409k1 (11)
   sect409r1 (12)
   sect571k1 (13)
   sect571r1 (14)

   // Non-FIPS curves
   secp256k1 (22)

A new system property is available to define a list of enabled curves.

 jdk.tls.namedGroups="secp521r1, secp256r1, secp384r1"

The values for named curves must be separated with a comma.
If the system property is not defined or the value is empty, the default
curves and preferences are used.

Service refresh 8 fix pack 41 (February 2017)

Changes to IBMJSSE2 cipher support

3DES is now considered to be a weak cipher and should not be used unless a stronger cipher is not available in the client requested cipher suites. The DESede algorithm is added to the list of algorithms that are disabled by default. For more information, see "Disabling cryptographic algorithms" in the product documentation.

Go back to top

Service refresh 8 fix pack 7 (July 2015)

Partial fix for change in behavior for -Xshareclasses:destroyAll

In fix pack 3, a behavior change was reported for this option on z/OS platforms. See Change in behavior for -Xshareclasses:destroyAll .

Following a fix for the 64-bit JVM, the problem remains only on the 31-bit JVM. When the destroyAll option is invoked from a 31-bit JVM, 64-bit caches are not destroyed. The following message is displayed:

• JVMSHRC735I Use a 64-bit JVM to perform the requested operation on the 64-bit shared cache \"cachename\" as the 31-bit JVM cannot verify that the shared memory was created by the JVM











 

Service refresh 8 fix pack 3

Change in behavior for -Xshareclasses:destroyAll

Due to a current issue on z/OS, when the destroyAll option is invoked from a 31-bit Java virtual machine (JVM), 64-bit caches are not removed. Similarly, when the destroyAll option is invoked from a 64-bit JVM, 31-bit caches are not removed. The following message is displayed:

• JVMSHRC735I: Use a nn-bit JVM to perform the requested operation on the nn-bit shared cache \"cachename\" as the nn-bit JVM cannot verify that the shared memory was created by the JVM.

Go back to top

Service refresh 6

Unexpected XSLT error on extension elements or extension functions when Java security is enabled

Any attempt to use extension elements or extension functions when Java security is enabled, results in a javax.xml.transform.TransformerException error during XSLT processing. This change in behavior is introduced to enhance security. For more information, see "Unexpected XSLT error on extension elements or extension functions when Java security is enabled" in the product documentation.

Go back to top

Service refresh 5 fix pack 2

This fix pack includes a change to the default value for the RMI property java.rmi.server.useCodebaseOnly from false to true, which might cause unexpected errors for applications that use RMI. For more information, see http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/enhancements-7.html .

On Windows, improvements are made to the way that Runtime.exec decodes command strings. However, applications specifying commands that contain spaces in the program name, or that use quotation marks incorrectly, might fail to start. For more information, including guidance on resolving problems, see http://www.oracle.com/technetwork/java/javase/7u21-relnotes-1932873.html#jaruntime .

Go back to top

Service refresh 5 fix pack 1

This fix pack contains a security fix for the Oracle security vulnerability, CVE-2013-0169 . For any further security fixes in this release, see Security alerts .

A security enhancement is included to correctly validate certificates on jar files of applications. After upgrading, a CertificateException occurs for any applications in one of the following scenarios:

• The application jar is not properly signed.
• The application jar has incorrect certificates.
• A certificate in the certificate chain is revoked.

To avoid these exceptions, make sure that your application jars are signed with valid certificates before upgrading from an earlier release. This issue relates to APAR IV38456.

Go back to top

Service refresh 5

The following change is included in this release:

Non-blocking registration of interested operations with selectors on the AIX operating system

In this release, the implementation of the registration of interested operations with the java.nio.channels.Selector class has been modified to avoid blocked threads.

In previous releases, this implementation could cause blocking of threads on the AIX® operating system. If a Java application used the java.nio.channels.SelectionKey.interestOps() method to register an interested operation with a Selector object that was engaged in a polling operation, the registering thread could be blocked. A thread that is blocked in this way can cause the application to hang or timeout. The following Java stack traces from such a situation show that the first thread is performing a poll operation, and the second thread is blocked:

3XMTHREADINFO      "Thread-2" TID:0x31E65800, j9thread_t:0x31C9764C, state:R, prio=5
3XMTHREADINFO1            (native thread ID:0x2AA00A5, native priority:0x5, native policy:UNKNOWN)
4XESTACKTRACE          at sun/nio/ch/PollArrayWrapper.poll0(Native Method)
4XESTACKTRACE          at sun/nio/ch/PollArrayWrapper.poll(PollArrayWrapper.java:116)
4XESTACKTRACE          at sun/nio/ch/PollSelectorImpl.doSelect(PollSelectorImpl.java:57)
4XESTACKTRACE          at sun/nio/ch/SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
4XESTACKTRACE          at sun/nio/ch/SelectorImpl.select(SelectorImpl.java:80)
4XESTACKTRACE          at sun/nio/ch/SelectorImpl.select(SelectorImpl.java:84)
4XESTACKTRACE          at BlockIntOpsReg.run(BlockIntOpsReg.java:18)
4XESTACKTRACE          at java/lang/Thread.run(Thread.java:735)


3XMTHREADINFO      "main" TID:0x30A65500, j9thread_t:0x301162D4, state:B, prio=5
3XMTHREADINFO1            (native thread ID:0x14A005F, native priority:0x5, native policy:UNKNOWN)
4XESTACKTRACE          at sun/nio/ch/SelectionKeyImpl.nioInterestOps(SelectionKeyImpl.java:103)
4XESTACKTRACE          at sun/nio/ch/SelectionKeyImpl.interestOps(SelectionKeyImpl.java:65)
4XESTACKTRACE          at BlockIntOpsReg.main(BlockIntOpsReg.java:40)

This thread blocking was caused by the pollset implementation using a Java cache of limited size to store requests for registration of interested operations. When the cache reached its size limit, the implementation attempted to register all the requests in the Java cache into the native AIX pollset cache, which could result in blocked threads. From this release, the Java cache size is unlimited, and interested operations are registered just before the next poll operation, to avoid blocking of threads.

For more information about I/O polling on the AIX operating system, see the following developerWorks article: Efficient I/O event polling through the pollset interface on AIX .

Go back to top

Service refresh 2

The following change is included in this release:

KeyboardFocusManager implementation

This change relates to Oracle security vulnerability CVE-2012-0502 .
The KeyboardFocusManager specification explicitly allows a single, global KeyboardFocusManager for all applets. Some public methods are unsafe for such implementations.
As a result of the fix, the following methods now throw a java.lang.SecurityException if they are invoked on a java.awt.KeyboardFocusManager that is not the current java.awt.KeyboardFocusManager for the calling thread's context:

• java.awt.KeyboardFocusManager.setGlobalFocusOwner(Component focusOwner)
• java.awt.KeyboardFocusManager.clearGlobalFocusOwner()
• java.awt.KeyboardFocusManager.setGlobalPermanentFocusOwner(Component PermanentFocusOwner)
• java.awt.KeyboardFocusManager.setGlobalFocusedWindow(Window focusedWindow)
• java.awt.KeyboardFocusManager.setGlobalActiveWindow(Window activeWindow)
• java.awt.KeyboardFocusManager.setGlobalCurrentFocusCycleRoot(Container newFocusCycleRoot)

Go back to top

Comparative Oracle build levels

The following table indicates the Oracle FCS build level that has comparative functionality to recent releases of the IBM SDK:

Go back to top