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

[Ron Pressler]

On Wed, 8 Jun 2022 22:40:02 GMT, Dean Long <dlong at openjdk.org> wrote:

>> @dean-long Which sp, though? The frame's ultimate sp? I I think interpreted frames don't know their sp when they're first constructed (and not sure about when they return). Or it could be the actual location of the return address, but I don't know what that means for the protection mechanism. On the other hand, the preserved fp is always the return address's location minus 1 anyway.
>> 
>> Either way, it's not the right value for Loom. We'll need to consider 1. how important is PAC for _Java_ frames, and 2. if it is important, what second value to use that is invariant under stack copying.
>
> @pron I don't think there is any reason why interpreted frames couldn't continue to use FP while compiled frames use SP.  It's not clear how useful PAC is for Java code at dynamic locations (how would the exploit find the ROP gadgets?).  I don't think there is a useful alternative to FP/SP that is invariant under stack copying.

@dean-long Thing is, I don't know the requirement on the second value. [This](https://developer.arm.com/documentation/102433/0100/Return-oriented-programming) suggests that even a constant value of zero can be used, and perhaps we could do better (?) by using some thread/continuation id, assuming this is useful at all for Java frames. In particular, if the attacker knows the location of the return address, then they also know the value of (a preserved) fp. Perhaps @nick-arm can enlighten us.

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

PR: https://git.openjdk.java.net/jdk/pull/9067