Document ARM64 unwind handling for return address signing

[mstorsjo]

This is deduced/guessed from studying the output of MSVC with the /d2guardsignret flag. Hopefully someone with insight into the unwinder internals can confirm whether this indeed is the case.

I made up an unwind opcode name for this opcode (0xfc, sign_ra) - other suggestions are welcome.

I'm not entirely sure about whether this is how it is handled for the packed functions, but this would intuitively be how it works.

Since there are two parallel instructions for signing return addresses, paciasp and pacibsp, the unwinder would need to know which one to use for signing - MSVC seems to generate pacibsp (togeter with autibsp) - is there any other similar opcode for paciasp, or is that one unsupported for Windows unwinding purposes?

[prmerger-automator]

@mstorsjo : Thanks for your contribution! The author(s) have been notified to review your proposed change.

[opbld30]

Learn Build status updates of commit 21e4902:

✅ Validation status: passed

File	Status	Preview URL	Details
docs/build/arm64-exception-handling.md	✅Succeeded

For more details, please refer to the build report.

Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.

For any questions, please:

• Try searching the learn.microsoft.com contributor guides
• Post your question in the Learn support channel

[Court72]

@corob-msft

Can you review the proposed changes? IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

[colin-home]

@mstorsjo

Thanks for the proposal. As near as I can tell, the actual opcode is known as pac_sign_return_address, and the logic is largely as you've divined. There appears to be a flag that lets the signing/verifying opcodes be replaced with nops, so there's an additional bit of complexity involved somewhere. At least, I think so, if I'm reading things correctly, which is always a question. The signing step is "Step 1" in the internal comments, and saving registers is "Step 2", so we should probably renumber those and the following steps accordingly.

To get the inside story, I'm invoking @laurenprinn and @sigatrev for their takes. (I'd invoke James McNellis, but he's moved on to smaller and more playful things at Roblox.) I don't feel qualified to sign off on my own.

[prmerger-automator]

@mstorsjo : Thanks for your contribution! The author(s) have been notified to review your proposed change.

[mstorsjo]

Thanks for the proposal. As near as I can tell, the actual opcode is known as pac_sign_return_address, and the logic is largely as you've divined. There appears to be a flag that lets the signing/verifying opcodes be replaced with nops, so there's an additional bit of complexity involved somewhere. At least, I think so, if I'm reading things correctly, which is always a question. The signing step is "Step 1" in the internal comments, and saving registers is "Step 2", so we should probably renumber those and the following steps accordingly.

Thanks! I've updated the PR to use the correct name for the opcode, and renumbered the steps for the packed form.

[opbld33]

Learn Build status updates of commit 1887d8c:

✅ Validation status: passed

File	Status	Preview URL	Details
docs/build/arm64-exception-handling.md	✅Succeeded

For more details, please refer to the build report.

Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.

For any questions, please:

• Try searching the learn.microsoft.com contributor guides
• Post your question in the Learn support channel

[sigatrev]

The x30/lr inconsistency should be fixed, but this otherwise looks good to me.

[prmerger-automator]

@mstorsjo : Thanks for your contribution! The author(s) have been notified to review your proposed change.

[opbld33]

Learn Build status updates of commit f510c83:

✅ Validation status: passed

File	Status	Preview URL	Details
docs/build/arm64-exception-handling.md	✅Succeeded

For more details, please refer to the build report.

Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.

For any questions, please:

• Try searching the learn.microsoft.com contributor guides
• Post your question in the Learn support channel

[mstorsjo]

@sigatrev BTW, are you able to comment on what the Windows unwinder implementation does, if the actual code does use PAC (and running on HW that exposes it, with a Windows configuration that has taken it into use), but the unwind info is lacking these opcodes? (That's the current status quo if building code with Clang today, with -mbranch-protection=standard.) I.e., does the unwinder implicitly run xpaci on the return address after finishing RtlVirtualUnwind, or does it only do that (or similar) if explicitly told so by an unwinding opcode?

[pmsjt]

@sigatrev BTW, are you able to comment on what the Windows unwinder implementation does, if the actual code does use PAC (and running on HW that exposes it, with a Windows configuration that has taken it into use), but the unwind info is lacking these opcodes? (That's the current status quo if building code with Clang today, with -mbranch-protection=standard.) I.e., does the unwinder implicitly run xpaci on the return address after finishing RtlVirtualUnwind, or does it only do that (or similar) if explicitly told so by an unwinding opcode?

It must be explicitly present.

[mstorsjo]

@sigatrev BTW, are you able to comment on what the Windows unwinder implementation does, if the actual code does use PAC (and running on HW that exposes it, with a Windows configuration that has taken it into use), but the unwind info is lacking these opcodes? (That's the current status quo if building code with Clang today, with -mbranch-protection=standard.) I.e., does the unwinder implicitly run xpaci on the return address after finishing RtlVirtualUnwind, or does it only do that (or similar) if explicitly told so by an unwinding opcode?

It must be explicitly present.

Ok, thanks for the clarification!

[prmerger-automator]

@corob-msft : Thanks for your contribution! The author(s) have been notified to review your proposed change.

[colin-home]

@mstorsjo
Thanks for the useful update.

[opbld30]

Learn Build status updates of commit 4547444:

✅ Validation status: passed

File	Status	Preview URL	Details
docs/build/arm64-exception-handling.md	✅Succeeded

For more details, please refer to the build report.

Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.

For any questions, please:

• Try searching the learn.microsoft.com contributor guides
• Post your question in the Learn support channel

[colin-home]

#sign-off