JDK-8209951 : Problematic sparc intrinsic: com.sun.crypto.provider.CipherBlockChaining
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u71,9,10,11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris
  • CPU: sparc
  • Submitted: 2018-08-24
  • Updated: 2024-07-16
  • Resolved: 2019-01-31
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 13 JDK 8 Other
11.0.4-oracleFixed 13 b07Fixed 8u221Fixed openjdk8u222Fixed
Related Reports
Relates :  
JDK-8219513 - compiler/codegen/aes/TestCipherBlockChainingEncrypt.java timeout on Solaris-sparc
Description
Seeing some random test failures involving these hotspot intrinsics :
com.sun.crypto.provider.CipherBlockChaining::decrypt
com.sun.crypto.provider.CipherBlockChaining::encrypt

# JRE version: Java(TM) SE Runtime Environment (8.0_71-b15) (build 1.8.0_71-b15)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.71-b15 mixed mode solaris-sparc compressed oops)
# Problematic frame:
# J 1082 C2 com.sun.crypto.provider.CipherCore.doFinal([BII[BI)I (640 bytes) @ 0xffffffff6bb24f84 [0xffffffff6bb24b20+0x464]

Originally I saw it in this testcase: jdk/test/com/sun/crypto/provider/Cipher/PBE/PBESameBuffer/PBESameBuffer.java 

I've managed to reduce that test case code and will attach to bug. (AESIntrinsics.java). I've only seen this failure (after a few minutes of running) on solaris 10 platforms to date. I tried on solaris 11 and could not reproduce. I was only able to reproduce on JDK 8u also. JDK 11 doesn't run on solaris 10 which was the test system OS I had.

Will attach test output from failing system. I've tested various JDK versions and these are my findings to date : 

8u66: no failure
8u71: failure
I can reproduce the failure on current jdk8u-dev builds also.

I don't see failure if I use the -XX:-UseAESIntrinsics option.
Comments
Note that -XX:-UseCompressedOops is a workaround, as it's the heap base we use and fail to restore.
26-03-2019
Fix Request Backporting this fix fixes a corner case on SPARC, adds the new test, and keeps JDK codebases in sync. The patch applies cleanly to 11u, applies with shuffle to 8u (and I had to put the test to new location, test/compiler/8209951/TestCipherBlockChainingEncrypt.java). New test works fine on Linux x86_64 in both 11u and 8u. Unfortunately, there is no way for me to test SPARC.
19-03-2019
URL: http://hg.openjdk.java.net/jdk/jdk/rev/bf4c38b9afaf User: kevinw Date: 2019-01-31 19:09:40 +0000
31-01-2019
http://cr.openjdk.java.net/~fmatte/8209951/webrev.00/
22-01-2019
Sean is right intrinsics stubs are hotspot/compiler group responsibility. I see that G6 is modified in generate_cipherBlockChaining_decryptAESCrypt_Parallel() at next line: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/26c65bb80287/src/cpu/sparc/vm/stubGenerator_sparc.cpp#l4486 The code calls save_frame() but it does not save G* registers. Only G1, G3, G4, G5 are saved on call based on our calling convention. The fix is to save on stack G6 before it is used in code. Or don't use it. I see it is used to preserve value in F50 register. We should use other register instead of G6 or save F50 on stack. Note, the fixed should be ported to all JDK versions which has this code. Which includes the latest JDK sources.
17-01-2019
I would disagree with the previous update. The issue only appears after the compiler performs intrinsics on com.sun.crypto.provider.CipherBlockChaining::encrypt Intrinsics is firmly in the hotspot area. The generate_cipherBlockChaining_encryptAESCrypt() method most likely has an incorrect assumption on how keyLength is calculated (the change in JDK-8138589) See http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/26c65bb80287/src/cpu/sparc/vm/stubGenerator_sparc.cpp#l3637
15-11-2018
I am denying the fact that there is any compiler issue here. In CipherCore.java -> finalNoPadding -> cipher.decryptFinal(in, inOfs, len, out, outOfs); "cipher.decryptFinal" - corrupts the out buffer, that it results crash in "unpad" where access to "out" buffer is made. This seems to be an issue with address aligning as the issue is specific to solaris 10 moving to "security-libs/javax.crypt"
15-11-2018
Thanks Sean... This regression started from 8u71 b04 due to JDK-8138589, Changeset causing this issue - http://closedjdk.us.oracle.com/jdk8u/jdk8u71/jdk/rev/5ea62bb625b6 There is one liner change. - new PBEKeySpec(passwdChars, salt, iCount, blkSize * 8); + new PBEKeySpec(passwdChars, salt, iCount, keyLength); Reverting back the change, seems to fix this issue (verified on 8u) Need to analyze more to identify why only on solaris 10, it has generated bad C2 code?
06-11-2018
Discussed with Fairoz; he will sync with [~coffeys] to determine what's next
04-10-2018
AES 256 necessary to reproduce this. Note that unlimited crypto became default since 8u161 via JDK-8170157 Older installs require unlimited JCE jurisdiction files to be copied in.
24-08-2018