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

Andrew Dinn adinn at redhat.com
Wed Sep 21 09:35:22 UTC 2016

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?


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

More information about the hotspot-dev mailing list