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

[Vladimir Kozlov]

Looks good.

Thanks,
Vladimir

On 11/7/16 3:21 AM, Rahul Raghavan wrote:
> Hi,
>
> Request review for closed bug fix - JDK-8159035.
>
> <webrev> - http://cr.openjdk.java.net/~rraghavan/8159035/webrev.03/
>
> Notes:
>
> 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)
>
>
> Thanks,
> Rahul
>