RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64 [v25]

[Doug Simon]

On Tue, 7 Feb 2023 06:14:24 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> The problem with `JVMCIGlobals::check_jvmci_supported_gc` is that it does not give the compiler a chance to specify whether it supports a given GC.
>> Instead, we want a JVMCI upcall like `jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.isGCSupported(int)`.
>
> Thanks for your reply. But I'm afraid I'm still a bit confused.
> 
> 1) flag `_rop_protection` is set inside function `VM_Version::initialize()`. The execution flow is `create_vm -> init_globals -> VM_Version_init -> VM_Version::initialize()`.
> 2) I suppose compilers (including JVMCI compiler) are initialized after `init_global()` function. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/threads.cpp#L685~L707. Hence I suppose we cannot call JVMCI methods before this site, right?
> 
> If so, I'm afraid it's a bit late for VM to ask the compiler whether it supports PAC-RET after the compiler initialization, and to disable PAC-RET if the JVMCI compiler doesn't support it, mainly because some stubs are generated already between `init_global()` and compiler initialization, and in these stubs, flag `_rop_protection` is used to generate PAC-related code, e.g., `SharedRuntime::generate_stubs() -> generate_deopt_blob() -> protect_return_address()`.
> 
> Please correct me if there is something I misunderstood. Thanks.

Ah ok, I did not pay attention to the VM lifecycle constraints in setting this flag. We could do the JVMCI check in `CompileBroker::compilation_init_phase2` but that would mean forcing eager initialization of JVMCI which, in turn, would impact VM startup.
For now, we will just add a check into Graal that `UseBranchProtection` is not set, exiting the VM if it is. At the same time, we will work on adding support for this.

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

PR: https://git.openjdk.org/jdk/pull/6334