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

[Hao Sun]

On Tue, 4 Apr 2023 08:58:35 GMT, Andrew Haley <aph 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 should be preserved to make it easy to find this modifier in case of some exception scenarios (Recall the reason why we fail to use SP as the modifier).
>> 
>> 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.
>> 
>> ### Implementation of Zero modifier
>> 
>> Here list the key updates of this patch.
>> 
>> 1. vm_version_aarch64.cpp
>> 
>> Remove the constraint on "enable-preview" and "PreserveFramePointer".
>> 
>> 2. macroAssembler_aarch64.cpp
>> 
>> For utility protect_return_address(), 1) use PACIAZ/PACIZA instructions directly. 2) argument "temp_reg" is removed since all functions use the same modifier. 3) all the use sites are updated accordingly. This involves the updates in many files.
>> 
>> Similar updates are done to utility authenticate_return_address().
>> 
>> Besides, aarch64.ad and AArch64TestAssembler.java are updated accordingly.
>> 
>> 3. pauth_linux_aarch64.inline.hpp
>> 
>> For utilities pauth_sign_return_address() and
>> pauth_authenticate_return_address(), remove the second argument and pass value zero to r16 register.
>> 
>> Similarly, all the use sites are updated as well. This involves the updates in many files.
>> 
>> 6. continuationHelper_aarch64.inline.hpp
>> 
>> Introduce return_pc_at() and patch_pc_at() to avoid directly reading the saved PC or writing new signed PC on the stack in shared code.
>> 
>> 7. Minor updates
>> 
>> (1) sharedRuntime_aarch64.cpp: Add the missing
>> authenticate_return_address() use for function gen_continuation_enter(). In functions generate_deopt_blob() and generate_uncommon_trap_blob(), remove the authentication on the caller (3) frame since the return address is not used.
>> 
>> (2) stubGenerator_aarch64.cpp: Add the missing
>> authenticate_return_address() use for function generate_cont_thaw().
>> 
>> (3) runtime.cpp: enable the authentication.
>> 
>> ### Test
>> 
>> 1. Cross compilations on arm32/s390/ppc/riscv passed.
>> 2. zero build and x86 build passed.
>> 3. tier1~3 passed on Linux/AArch64 w/ and w/o PAC-RET.
>> 
>> Co-Developed-by: Nick Gasson <Nick.Gasson at arm.com>
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8277204
>> [2] https://openjdk.org/jeps/425
>> [3] https://github.com/openjdk/jdk/pull/9067
>> [4] https://bugs.openjdk.org/browse/JDK-8288023
>> [5] https://bugs.openjdk.org/browse/JDK-8301819
>> [6] https://openjdk.org/jeps/444
>> [7] https://www.usenix.org/conference/usenixsecurity21/presentation/liljestrand
>> [8] https://github.com/openjdk/jdk/pull/10441
>
> src/hotspot/cpu/aarch64/continuationHelper_aarch64.inline.hpp line 72:
> 
>> 70: 
>> 71: inline address ContinuationHelper::return_pc_at(intptr_t* sp) {
>> 72:   return pauth_strip_pointer(*(address*)sp);
> 
> This is the return address. it's called `return_address` elsewhere.

I used `return_pc_at()` following the usage of `ContinuationHelper::Frame::return_pc()` and `ContinuationHelper::InterpretedFrame::return_pc()`.

How about `get_pc_at()` or `return_address_at()`? 
Thanks.

> src/hotspot/cpu/aarch64/continuationHelper_aarch64.inline.hpp line 76:
> 
>> 74: 
>> 75: inline void ContinuationHelper::patch_pc_at(intptr_t* sp, address pc) {
>> 76:   *(address*)sp = pauth_sign_return_address(pc);
> 
> This is a bad name. We're not patching the PC.

Thanks for your code review.

>From `ContinuationHelper::Frame::patch_pc(const frame& f, address pc)` and `void frame::patch_pc(Thread* thread, address pc)`, I thought "patch_pc" means replacing the original PC with the new one, i.e. the argument PC.

In this function `ContinuationHelper::patch_pc_at(intptr_t* sp, address pc)`, I followed the notion that **updating the original PC at address SP with the argument PC**. That's why I used "patch_pc_at".

If you think it's not a good name, how about `set_pc_at()`?
Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13322#discussion_r1159230915
PR Review Comment: https://git.openjdk.org/jdk/pull/13322#discussion_r1159230844