RFR: 8159035: com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length value as 0 (original) (raw)

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Nov 7 18:04:51 UTC 2016

Looks good.

Thanks, Vladimir

On 11/7/16 3:21 AM, Rahul Raghavan wrote:

Hi,

Request review for closed bug fix - JDK-8159035. - http://cr.openjdk.java.net/~rraghavan/8159035/webrev.03/ Notes: 1. - 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 cipherBlockChainingdecryptAESCrypt' 2. Found root cause of the reported jvm crash for sparc - Crash happens at 'generatecipherBlockChainingdecryptAESCryptParallel()' [stubGeneratorsparc.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 fix proposed in Java wrapper method side [CipherBlockChaining.java]. 4. The same issue in aarch64 (JDK-8167595) was fixed earlier in stubGeneratoraarch64. So once above 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 - implCrypt() / CounterMode.java - implEncodeISOArray() / ISO88591.java Confirmed no Issues for with jprt testing (-testset hotspot, core)

Thanks, Rahul

More information about the core-libs-dev mailing list