[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