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

[Xueming Shen]

change in 8859-1 looks good.

sherman

> 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
>>