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

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


More information about the aarch64-port-dev mailing list