Document ARM64 unwind handling for return address signing by mstorsjo · Pull Request #4202 · MicrosoftDocs/cpp-docs

mstorsjo · 2022-10-04T11:58:07Z

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 · 2022-10-04T11:58:21Z

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

opbld30 · 2022-10-04T11:59:52Z

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 · 2022-10-04T15:10:46Z

@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 · 2022-10-06T01:51:02Z

@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 · 2022-10-06T09:06:50Z

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

mstorsjo · 2022-10-06T09:07:42Z

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 · 2022-10-06T09:08:52Z

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 · 2022-10-10T19:25:21Z

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

opbld33 · 2022-10-10T19:26:20Z

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 · 2022-10-10T20:56:26Z

@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 · 2022-10-10T21:49:34Z

@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 · 2022-10-10T22:02:10Z

@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 · 2022-10-11T00:30:21Z

@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 · 2022-10-11T00:32:35Z

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 · 2022-10-11T00:33:04Z

#sign-off

This got documented upstream in MicrosoftDocs/cpp-docs#4202. Differential Revision: https://reviews.llvm.org/D135275

This was documented upstream in MicrosoftDocs/cpp-docs#4202. Differential Revision: https://reviews.llvm.org/D135276

This new opcode was initially documented as "pac_sign_return_address" in MicrosoftDocs/cpp-docs#4202, but was soon afterwards renamed into "pac_sign_lr" in MicrosoftDocs/cpp-docs#4209, as the other name was unwieldy, and there were no other external references to that name anywhere. Rename our external .seh assembler directive - it hasn't been merged for very long yet, so there's probably no external use to account for. Rename all other internal references to the opcode similarly. Differential Revision: https://reviews.llvm.org/D135762

This got documented upstream in MicrosoftDocs/cpp-docs#4202. Differential Revision: https://reviews.llvm.org/D135275

This was documented upstream in MicrosoftDocs/cpp-docs#4202. Differential Revision: https://reviews.llvm.org/D135276

This new opcode was initially documented as "pac_sign_return_address" in MicrosoftDocs/cpp-docs#4202, but was soon afterwards renamed into "pac_sign_lr" in MicrosoftDocs/cpp-docs#4209, as the other name was unwieldy, and there were no other external references to that name anywhere. Rename our external .seh assembler directive - it hasn't been merged for very long yet, so there's probably no external use to account for. Rename all other internal references to the opcode similarly. Differential Revision: https://reviews.llvm.org/D135762

This case did get documented upstream, in MicrosoftDocs/cpp-docs#4202, and the way that llvm-readobj prints it, implemented in that commit, is correct.

prmerger-automator Bot added the do-not-merge label Oct 4, 2022

prmerger-automator Bot requested a review from colin-home October 4, 2022 11:58

prmerger-automator Bot assigned colin-home Oct 4, 2022

prmerger-automator Bot added Change sent to author cpp-tools/tech visual-cpp/prod labels Oct 4, 2022

prmerger-automator Bot added the qualifies-for-auto-merge label Oct 4, 2022

prmerger-automator Bot added the aq-pr-triaged Tracking label for the PR review team label Oct 4, 2022

mstorsjo force-pushed the arm64-unwind-pac branch from 21e4902 to 1887d8c Compare October 6, 2022 09:06

prmerger-automator Bot removed the qualifies-for-auto-merge label Oct 6, 2022

prmerger-automator Bot added the qualifies-for-auto-merge label Oct 6, 2022

sigatrev suggested changes Oct 10, 2022

View reviewed changes

Comment thread docs/build/arm64-exception-handling.md Outdated

Document ARM64 unwind handling for return address signing

f510c83

mstorsjo force-pushed the arm64-unwind-pac branch from 1887d8c to f510c83 Compare October 10, 2022 19:24

prmerger-automator Bot removed the qualifies-for-auto-merge label Oct 10, 2022

prmerger-automator Bot added the qualifies-for-auto-merge label Oct 10, 2022

sigatrev approved these changes Oct 10, 2022

View reviewed changes

Update date, fix step numbers

4547444

prmerger-automator Bot removed the qualifies-for-auto-merge label Oct 11, 2022

colin-home approved these changes Oct 11, 2022

View reviewed changes

prmerger-automator Bot added the qualifies-for-auto-merge label Oct 11, 2022

prmerger-automator Bot added ready-to-merge and removed do-not-merge labels Oct 11, 2022

colin-home merged commit 8e6bd58 into MicrosoftDocs:main Oct 11, 2022

mstorsjo deleted the arm64-unwind-pac branch October 11, 2022 08:14

mstorsjo added a commit to llvm/llvm-project that referenced this pull request Oct 11, 2022

[llvm-readobj] Decode the new ARM64 SEH info for return address signing

6ad4fda

This got documented upstream in MicrosoftDocs/cpp-docs#4202. Differential Revision: https://reviews.llvm.org/D135275

mstorsjo added a commit to llvm/llvm-project that referenced this pull request Oct 12, 2022

[AArch64] Add support for the SEH opcode for return address signing

c43bff6

This was documented upstream in MicrosoftDocs/cpp-docs#4202. Differential Revision: https://reviews.llvm.org/D135276

veselypeta pushed a commit to veselypeta/cherillvm that referenced this pull request May 28, 2024

[AArch64] Add support for the SEH opcode for return address signing

4eb8199

This was documented upstream in MicrosoftDocs/cpp-docs#4202. Differential Revision: https://reviews.llvm.org/D135276

Conversation

mstorsjo commented Oct 4, 2022

Uh oh!

prmerger-automator Bot commented Oct 4, 2022

Uh oh!

opbld30 commented Oct 4, 2022

✅ Validation status: passed

Uh oh!

Court72 commented Oct 4, 2022

Uh oh!

colin-home commented Oct 6, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

prmerger-automator Bot commented Oct 6, 2022

Uh oh!

mstorsjo commented Oct 6, 2022

Uh oh!

opbld33 commented Oct 6, 2022

✅ Validation status: passed

Uh oh!

sigatrev left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

prmerger-automator Bot commented Oct 10, 2022

Uh oh!

opbld33 commented Oct 10, 2022

✅ Validation status: passed

Uh oh!

mstorsjo commented Oct 10, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pmsjt commented Oct 10, 2022

Uh oh!

mstorsjo commented Oct 10, 2022

Uh oh!

prmerger-automator Bot commented Oct 11, 2022

Uh oh!

colin-home left a comment

Choose a reason for hiding this comment

Uh oh!

opbld30 commented Oct 11, 2022

✅ Validation status: passed

Uh oh!

colin-home commented Oct 11, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

colin-home commented Oct 6, 2022 •

edited

Loading

mstorsjo commented Oct 10, 2022 •

edited

Loading