RFR: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret [v10]

[Dean Long]

On Fri, 15 Sep 2023 06:11:38 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> ### Background
>> 
>> 1. PAC-RET branch protection was initially implemented on Linux/AArch64 in JDK-8277204 [1].
>> 
>> 2. However, it was broken with the introduction of virtual threads [2], mainly because the continuation freeze/thaw mechanism would trigger stack copying to/from memory, whereas the saved and signed LR on the stack doesn't get re-signed accordingly.
>> 
>> 3. PR-9067 [3] tried to implement the re-sign part, but it was not accepted because option "PreserveFramePointer" is always turned on by PAC-RET but this would slow down virtual threads by ~5-20x.
>> 
>> 4. As a workaround, JDK-8288023 [4] disables PAC-RET when preview language features are enabled. Note that virtual thread is one preview feature then.
>> 
>> 5. Virtual thread will become a permanent feature in JDK-21 [5][6].
>> 
>> ### Goal
>> 
>> This patch aims to make PAC-RET compatible with virtual threads.
>> 
>> ### Requirements of virtual threads
>> 
>> R-1: Option "PreserveFramePointer" should be turned off. That is, PAC-RET implementation should not rely on frame pointer FP. Otherwise, the fast path in stack copying will never be taken.
>> 
>> R-2: Use some invariant values to stack copying as the modifier, so as to avoid the PAC re-sign for continuation thaw, as the fast path in stack copying doesn't walk the frame.
>> 
>> Note that more details can be found in the discussion [3].
>> 
>> ### Investigation
>> 
>> We considered to use (relative) stack pointer SP, thread ID, PACStack [7] and value zero as the candidate modifier.
>> 
>> 1. SP: In some scenarios, we need to authenticate the return address in places where the current SP doesn't match the SP on function entry. E.g. see the usage in Runtime1::generate_handle_exception(). Hence, neither absolute nor relative SP works.
>> 
>> 2. thread ID (tid): It's invariant to virtual thread, but it's nontrivial to access it from the JIT side. We need 1) firstly resolve the address of current thread (See [8] as an example), and 2) get the tid field in the way like java_lang_Thread::thread_id(). I suppose this would introduce big performance overhead. Then can we turn to use "rthread" register (JavaThread object address) as the modifier? Unfortunately, it's not an invariant to virtual threads and PAC re-sign is still needed.
>> 
>> 5. PACStack uses the signed return address of caller as the modifier to sign the callee's return address. In this way, we get one PACed call chain. The modifier should be saved into somewhere around the frame record. Inevitably, FP sh...
>
> Hao Sun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   break long lines

src/hotspot/os_cpu/linux_aarch64/pauth_linux_aarch64.inline.hpp line 57:

> 55:     register address r17 __asm("r17") = ret_addr;
> 56:     register address r16 __asm("r16") = 0;
> 57:     asm (PACIA1716 : "+r"(r17) : "r"(r16));

Can we use PACIZA or PACIA here so we don't force the use of r16/r17?

src/hotspot/os_cpu/linux_aarch64/pauth_linux_aarch64.inline.hpp line 69:

> 67:     register address r17 __asm("r17") = ret_addr;
> 68:     register address r16 __asm("r16") = 0;
> 69:     asm (AUTIA1716 : "+r"(r17) : "r"(r16));

AUTIZA or AUTIA?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13322#discussion_r1332214210
PR Review Comment: https://git.openjdk.org/jdk/pull/13322#discussion_r1332215314