Fix SSP issue with HW exceptions from JIT helpers#107665
Merged
janvorli merged 1 commit intodotnet:mainfrom Sep 11, 2024
Merged
Fix SSP issue with HW exceptions from JIT helpers#107665janvorli merged 1 commit intodotnet:mainfrom
janvorli merged 1 commit intodotnet:mainfrom
Conversation
The recent change that was fixing bad SSP updating during exception handling with funceval has also modified the way SSP is extracted for hardware exceptions. That works fine for many cases, but there is a problem when the exception occurs in a JIT helper. The `AjustContextForJITHelpers` uses only the basic `CONTEXT` structure for unwinding to the managed caller and so the SSP is not properly updated. That makes it off by one slot when we set it when continuing execution after catch. This change removes storing SSP for hardware exceptions in the FaultingExceptionFrame to mitigate the issue. It effectively returns to the way software exceptions use - scanning shadow stack for the instruction pointer of the frame to which it is going to resume after catch.
janvorli
commented
Sep 11, 2024
|
|
||
| save_reg_postrsp rcx, REDIRECT_FOR_THROW_CONTROL_FRAME_SIZE + 8h ; FaultingExceptionFrame | ||
| save_reg_postrsp rdx, REDIRECT_FOR_THROW_CONTROL_FRAME_SIZE + 10h ; Original RSP | ||
| save_reg_postrsp r8, REDIRECT_FOR_THROW_CONTROL_FRAME_SIZE + 18h ; SSP |
Member
Author
There was a problem hiding this comment.
I've changed the code to pass the SSP to the target function instead of storing it in the FaultingExceptionFrame so that the FaultingExceptionFrame::Init can zero it by default that's needed in all cases other than the funceval redirection.
Member
Author
|
cc: @tommcdon - I've re-tested it with the funceval diagnostics tests to make sure it still works correctly. |
jkotas
approved these changes
Sep 11, 2024
Member
Author
|
/backport to release/9.0 |
Contributor
|
Started backporting to release/9.0: https://github.com/dotnet/runtime/actions/runs/10808095425 |
4 tasks
jtschuster
pushed a commit
to jtschuster/runtime
that referenced
this pull request
Sep 17, 2024
The recent change that was fixing bad SSP updating during exception handling with funceval has also modified the way SSP is extracted for hardware exceptions. That works fine for many cases, but there is a problem when the exception occurs in a JIT helper. The `AjustContextForJITHelpers` uses only the basic `CONTEXT` structure for unwinding to the managed caller and so the SSP is not properly updated. That makes it off by one slot when we set it when continuing execution after catch. This change removes storing SSP for hardware exceptions in the FaultingExceptionFrame to mitigate the issue. It effectively returns to the way software exceptions use - scanning shadow stack for the instruction pointer of the frame to which it is going to resume after catch. Co-authored-by: Jan Vorlicek <jan.vorlicek@volny,cz>
sirntar
pushed a commit
to sirntar/runtime
that referenced
this pull request
Sep 30, 2024
The recent change that was fixing bad SSP updating during exception handling with funceval has also modified the way SSP is extracted for hardware exceptions. That works fine for many cases, but there is a problem when the exception occurs in a JIT helper. The `AjustContextForJITHelpers` uses only the basic `CONTEXT` structure for unwinding to the managed caller and so the SSP is not properly updated. That makes it off by one slot when we set it when continuing execution after catch. This change removes storing SSP for hardware exceptions in the FaultingExceptionFrame to mitigate the issue. It effectively returns to the way software exceptions use - scanning shadow stack for the instruction pointer of the frame to which it is going to resume after catch. Co-authored-by: Jan Vorlicek <jan.vorlicek@volny,cz>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The recent change that was fixing bad SSP updating during exception handling with funceval has also modified the way SSP is extracted for hardware exceptions. That works fine for many cases, but there is a problem when the exception occurs in a JIT helper. The
AjustContextForJITHelpersuses only the basicCONTEXTstructure for unwinding to the managed caller and so the SSP is not properly updated. That makes it off by one slot when we set it when continuing execution after catch.This change removes storing SSP for hardware exceptions in the FaultingExceptionFrame to mitigate the issue. It effectively returns to the way software exceptions use - scanning shadow stack for the instruction pointer of the frame to which it is going to resume after catch.
Close #107668