[aarch64-port-dev ] RFR: AArch64: SEGV in stub code cipherBlockChaining_decryptAESCrypt

[Ningsheng Jian]

Hi,

Any comments on this? I think we need a JIRA entry to track it.

Thanks,
Ningsheng

On 21 September 2016 at 17:35, Andrew Dinn <adinn at redhat.com> wrote:
> On 20/09/16 11:09, Ningsheng Jian wrote:
>> Jtreg test jdk/test/com/sun/crypto/provider/Cipher/CTS/CTSMode.java
>> failed with SIGSEGV on option "-Xcomp -XX:-TieredCompilation".
>>
>> The crash happens at stub code cipherBlockChaining_decryptAESCrypt.
>>
>> Checking the jdk source code CipherTextStealing.decryptFinal and its
>> callee CipherBlockChaining.decrypt/implDecrypt, we can see that
>> cipherLen which is passed to the stub code can be 0. The unexpected
>> len_reg value makes the load from invalid address.
>>
>> The following patch could fix this issue:
>>
>> http://people.linaro.org/~ningsheng.jian/webrev/cbc-stub-fix/webrev.00/
>>
>> It aligns with the Java code implementation and passed JTreg tests. To
>> make code consistent, I also update the encrypt part.
>>
>> Could someone please help to take a look at it?
>
> I think this patch looks like it will suffice to fix the AArch64 code.
> However, I don't understand why this is only an AArch64 issue. For
> example, it looks to me as if the x86_64 code is also susceptible to the
> same problem should input value 0 be passed in len_reg (c_rarg4). So,
> this might need fixing for all archs. Alternatively, it might be better
> fixed in the jdk (Java) code.
>
> Could someone from the hotspot compiler/runtime team confirm:
>
>  i) whether an input len_reg value of zero will cause a problem on x86
> (or, indeed, other archs)?
>
>  ii) whether that case should be caught in Java code or stub code?
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander