8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret #9067
Conversation
…c-ret The continuation free/thaw mechanism relies on being able to move thread stacks around in memory. However when PAC is enabled on supported AArch64 CPUs, the saved LR on the stack contains a "pointer authentication code" signed with the stack pointer at the time the frame was created. When a stack frame is relocated we need to re-sign the LR with the new stack pointer to ensure it authenticates successfully when the method returns. Also introduced ContinuationHelper::return_pc_at() to avoid directly reading the saved PC from the stack in shared code. On AArch64 with PAC it enabled it strips the PAC from the address after reading it, on all other platforms it just loads the PC from the stack as before.
|
|
|
/contributor add ahayward |
|
@nick-arm |
|
Could you explain what it is that this change attempts to do? Does every frame's returns address need to be patched on both freeze and thaw? If so, the slow path always has to be taken as we don't walk frames on the fast path. That slows down virtual threads by ~5-20x. |
|
If this feature requires re-signing every frame, then PAC-RET should be reconsidered for Java frames (though not native frames). In that case, the right fix for JDK 19 would be to disable this mode when preview is enabled. BTW, +PreserveFramePointer also causes a huge slowdown for virtual threads as it requires the slow path to be taken on every thaw. |
I agree. For the preview, I think we can do without -XX:UseBranchProtection=pac-ret. We should take some time to think about the best way to approach pac-ret with virtual threads. |
|
I've read some about the ARM PAC feature, and it seems that pointers are signed after being combined with any arbitrary value stored in some register. The current implementation uses a frame pointer value in the fp register as the other register, which is not only problematic for virtual threads, but with some future planned repurposing of that register. Perhaps some other secret value, that is amenable to copying stacks, could be used to achieve the same effect (although not in JDK 19, obviously). |
|
Yes the current implementation uses the frame pointer for signing/authentication so For now I can make another patch that disables PAC-RET when |
|
I don't see why we can't use the stack pointer instead of the frame pointer and get rid of the PreserveFramePointer requirement. |
|
@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. |
PAC-RET is not currently compatible with the continuation freeze/thaw mechanism used by virtual threads, and additionally -XX:UseBranchProtection=pac-ret enables PreserveFramePointer which prevents the use of the continuation thaw fast-path (about 15% slower for the "Skynet" JMH benchmark). So for now just disable PAC when --enable-preview was also passed. See some earlier discussion here: openjdk#9067
See #9102 |
|
@dean-long Thing is, I don't know the requirement on the second value. This 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. |
|
Zero works as well, as does any other value that's the same at function entry/exit. But the disadvantage of zero is that you get the same authentication code for each call to the function, whereas using SP gives you different codes as long as the stack depth is different. |
|
I'll close this one for now. |
The continuation free/thaw mechanism relies on being able to move thread stacks around in memory. However when PAC is enabled on supported AArch64 CPUs, the saved LR on the stack contains a "pointer authentication code" signed with the stack pointer at the time the frame was created. When a stack frame is relocated we need to re-sign the LR with the new stack pointer to ensure it authenticates successfully when the method returns.
Introduced
ContinuationHelper::return_pc_at()to avoid directly reading the saved PC from the stack in shared code. On AArch64 with PAC it enabled it strips the PAC from the address after reading it, on all other platforms it just loads the PC from the stack as before.Progress
Issue
Contributors
<ahayward@openjdk.org>Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/9067/head:pull/9067$ git checkout pull/9067Update a local copy of the PR:
$ git checkout pull/9067$ git pull https://git.openjdk.java.net/jdk pull/9067/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 9067View PR using the GUI difftool:
$ git pr show -t 9067Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/9067.diff