Bug ID: JDK-8167409 Invalid value passed to critical JNI function

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 10	Other
10 b33Fixed	openjdk8u252Fixed

On 10/10/2016 10:36 AM, Ioannis Tsakpinis wrote:
> This patch fixes invalid values passed to critical JNI functions on the
> System V AMD64 ABI (tested on Linux and MacOS).
> 
> Specifically, this bug occurs when the arguments of a JNI method with 6 or
> more parameters are shuffled to match the critical native function order.
> The ABI provides 6 registers for passing arguments, so a temporary register
> must be used to break the shuffling cycle (handled in ComputeMoveOrder). If
> the temp register happens to be used for a 64bit argument, the target
> register will receive an invalid value.
> 
> The fix is to call set2 when initializing the temp register to rbx. This
> marks the VMRegPair as a single physical register, which is important when
> copying 64bit values.
> 
> diff -r fec31089c2ef src/cpu/x86/vm/sharedRuntime_x86_64.cpp
> --- a/src/cpu/x86/vm/sharedRuntime_x86_64.cpp   Thu Oct 06 18:05:53 2016 -0700
> +++ b/src/cpu/x86/vm/sharedRuntime_x86_64.cpp   Sun Oct 09 22:44:54 2016 +0300
> @@ -2178,7 +2178,7 @@
>    // critical natives they are offset down.
>    GrowableArray<int> arg_order(2 * total_in_args);
>    VMRegPair tmp_vmreg;
> -  tmp_vmreg.set1(rbx->as_VMReg());
> +  tmp_vmreg.set2(rbx->as_VMReg());
> 
>    if (!is_critical_native) {
>      for (int i = total_in_args - 1, c_arg = total_c_args - 1; i >= 0;
> i--, c_arg--) {
> 
> The shuffling implementation on AArch64 is similar and the same fix may be
> required there, but I have not tested it.
> 
> Regards,
> Ioannis
>

Still under review.
18-02-2020
8u Fix Request Backporting this patch to fix this bug. Original patch does not apply cleanly to 8u due to path differences and missing file. 8u webrev: http://cr.openjdk.java.net/~fyang/8167409-8u-backport/webrev.00/ This updated copyright years for files changed or added. Also added one shell script Test8167409.sh to run the newly added test case in the original patch. Testing: Run full jtreg test with a x86-64 release build. Newly add test case fail without the patch and pass with the patch.
03-12-2019
Failure does not manifest yet, deferring bug to 10.
12-10-2016
Hi Jamsheed, here is a bug that might be interesting for you. If you'd rather like to work on something else, please assign it back to me. There is a related issue, JDK-8167408, I'll assign that to you as well (please assign that back as well if you don't want to look into it). Thank you! Best regards, Zoltan
11-10-2016
Critical functions are not used by JSR292, they are only used for crypto routines on solaris. Therefore, this problem does not currently affect an x86_64 VM (however, it will affect it once critical functions are used on x86_64 as well). ILW=invalid values might be passed to critical functions on x86_64,critical functions currently in-use on solaris only,don't use critical functions on x86_64 yet=HLL=P4
11-10-2016
Touches the same area as JDK-8167408. Maybe the two issues can be fixed with one change set.
11-10-2016
The code for critical JNI calls seems to have been added by the compiler team to optimize JSR292.
10-10-2016

Relates :	JDK-8167408 - Invalid critical JNI function lookup
Relates :	JDK-8191129 - AARCH64: Invalid value passed to critical JNI function