RFR: 8159035: com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length value as 0
anthony.scarpino at oracle.com
Thu Nov 10 22:33:16 UTC 2016
Your webrev changes for the crypto look fine.
On 11/07/2016 03:21 AM, Rahul Raghavan wrote:
> Request review for closed bug fix - JDK-8159035.
> <webrev> - http://cr.openjdk.java.net/~rraghavan/8159035/webrev.03/
> 1. <jbs> - https://bugs.openjdk.java.net/browse/JDK-8159035 - (com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length value as 0)
> Related issues -
> https://bugs.openjdk.java.net/browse/JDK-8076112 - 'Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics'
> https://bugs.openjdk.java.net/browse/JDK-8167595 - 'AArch64: SEGV in stub code cipherBlockChaining_decryptAESCrypt'
> 2. Found root cause of the reported jvm crash for sparc -
> Crash happens at 'generate_cipherBlockChaining_decryptAESCrypt_Parallel()' [stubGenerator_sparc.cpp]
> The implDecrypt can be called from CipherBlockChaining.decrypt, even with cipherLen as 0.
> But the same condition is not handled in the stub code and results in crash.
> (the same applicable for implEncrypt)
> 3. Though the reported case was for sparc, understood that same issue is present for x86, aarch64 (JDK-8167595).
> So in above <webrev> fix proposed in Java wrapper method side [CipherBlockChaining.java].
> 4. The same issue in aarch64 (JDK-8167595) was fixed earlier in stubGenerator_aarch64.
> So once above <webrev> is approved, I will initiate new hotspot webrev to revert this earlier 8167595 change.
> 5. Checked for any other similar cases with HotSpotIntrinsicCandidate support and found two cases as proposed in <webrev>
> - implCrypt() / CounterMode.java
> - implEncodeISOArray() / ISO_8859_1.java
> Confirmed no Issues for <webrev> with jprt testing (-testset hotspot, core)
More information about the hotspot-compiler-dev