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

[Andrew Haley]

On Fri, 7 Apr 2023 03:25:44 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:
> 
>   Rename return_pc_at and patch_pc_at
>   
>   Rename return_pc_at to return_address_at.
>   Rename patch_pc_at to patch_return_address_at.

> 
> Finally, we choose to use value zero as the modifier. Trivially, it's compatible with virtual threads. However, compared to FP modifier, this solution would reduce the strength of PAC-RET protection to some extent. E.g., you get the same authentication code for each call to the function, whereas using FP gives you different codes as long as the stack depth is different.

So, how important is this weakening? Could we keep the FP, but save a relative FP into the stack in compiled code? That wouldn't be hard, and might be a better fix. What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/13322#issuecomment-1674064242