RFR: 8371918: aarch64: Incorrect pointer dereference in TemplateInterpreterGenerator::generate_native_entry

[Kurt Miller]

On Sun, 16 Nov 2025 11:39:10 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> …rGenerator::generate_native_entry
>> 
>> I believe there's a incorrect pointer deference in `TemplateInterpreterGenerator::generate_native_entry()` in this part of the code:
>> 
>> 
>> // get native function entry point in r10
>>   {
>>     Label L;
>>     __ ldr(r10, Address(rmethod, Method::native_function_offset()));
>>     ExternalAddress unsatisfied(SharedRuntime::native_method_throw_unsatisfied_link_error_entry());
>>     __ lea(rscratch2, unsatisfied);
>>     __ ldr(rscratch2, rscratch2);
>>     __ cmp(r10, rscratch2);
>>     __ br(Assembler::NE, L);
>>     __ call_VM(noreg,
>>                CAST_FROM_FN_PTR(address,
>>                                 InterpreterRuntime::prepare_native_call),
>>                rmethod);
>>     __ get_method(rmethod);
>>     __ ldr(r10, Address(rmethod, Method::native_function_offset()));
>>     __ bind(L);
>>   }
>> 
>> 
>> If I understand this correctly, the entry point for unsatisfied link error is loaded into `rscratch2`. The next instruction, `ldr(rscratch2, rscratch2)`, dereferences that pointer and reads from the text segment the initial instructions at the entry point into `rscratch2`. It then compares the native method entry point in `r10` with the initial instructions loaded into `rscratch2` which will never match. I believe the intent here was to compare the native method entry point with the unsatisfied link error entry point and the `ldr(rscratch2, rscratch2)` instruction should be removed.
>> 
>> This was found on OpenBSD/aarch64. OpenBSD has a security feature where the text segments are marked execute only and do not allow reads independent of execution. the` ldr(rscratch2, rscratch2)` instruction causes a segfault because it is reading the text segment. While this bug was found on OpenBSD I believe it applies to all OS on aaarch64.
>> 
>> This change removes the errant aarch64 hotspot assembly instruction that was reading from libjvm.so .text segment.
>> 
>> Updated comment with markdown for code.
>
> Ah yes, I see.
> 
> The mistake was mine: I thought `__ cmpptr(rax, unsatisfied.addr(), rscratch1)` meant
>     `__ cmpptr(rax, unsatisfied, rscratch1)`. In other words, I missed the significance of `.addr()`.

@theRealAph Thank you for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28327#issuecomment-3543720726