Skip to content

Fix hardware exception context extraction on Rosetta#107188

Merged
janvorli merged 1 commit intodotnet:mainfrom
janvorli:fix-hardware-eh-context-extraction-on-rosetta
Aug 30, 2024
Merged

Fix hardware exception context extraction on Rosetta#107188
janvorli merged 1 commit intodotnet:mainfrom
janvorli:fix-hardware-eh-context-extraction-on-rosetta

Conversation

@janvorli
Copy link
Member

The recently added AVX support in hardware exception handling path on macOS x64 has introduced a problem when running under Rosetta. When we extract the floating point part of the context of the failing thread, the thread can have AVX or AVX512 active, or none of these. The code accidentally leaves CONTEXT_XSTATE set on the context even when no AVX was enabled on the thread.

Rosetta doesn't support AVX, so having CONTEXT_XSTATE set in the context flags can lead to later call to RtlRestoreContext attempting to set ymm registers using instructions that Rosetta cannot emulate and the app crashes due to that.

This doesn't happen in .NET 9, since we always clear the CONTEXT_XSTATE before exception handling stack unwinding. But in .NET 8, this causes stack overflow under Rosetta, since the attempt to execute the ymm instruction triggers the hardware exception handling again and again.

The recently added AVX support in hardware exception handling path on macOS x64
has introduced a problem when running under Rosetta.
When we extract the floating point part of the context of the failing thread,
the thread can have AVX or AVX512 active, or none of these. The code accidentally
leaves CONTEXT_XSTATE set on the context even when no AVX was enabled on the thread.

Rosetta doesn't support AVX, so having CONTEXT_XSTATE set in the context flags
can lead to later call to RtlRestoreContext attempting to set ymm registers using
instructions that Rosetta cannot emulate and the app crashes due to that.

This doesn't happen in .NET 9, since we always clear the CONTEXT_XSTATE before
exception handling stack unwinding. But in .NET 8, this causes stack overflow
under Rosetta, since the attemt to execute the ymm instruction triggers the
hardware exception handling again and again.
@janvorli janvorli added this to the 8.0.x milestone Aug 30, 2024
@janvorli janvorli requested a review from jkotas August 30, 2024 13:58
@janvorli janvorli self-assigned this Aug 30, 2024
@janvorli janvorli merged commit 47541bc into dotnet:main Aug 30, 2024
@janvorli
Copy link
Member Author

/backport to release/8.0-staging

@github-actions
Copy link
Contributor

jtschuster pushed a commit to jtschuster/runtime that referenced this pull request Sep 17, 2024
The recently added AVX support in hardware exception handling path on macOS x64
has introduced a problem when running under Rosetta.
When we extract the floating point part of the context of the failing thread,
the thread can have AVX or AVX512 active, or none of these. The code accidentally
leaves CONTEXT_XSTATE set on the context even when no AVX was enabled on the thread.

Rosetta doesn't support AVX, so having CONTEXT_XSTATE set in the context flags
can lead to later call to RtlRestoreContext attempting to set ymm registers using
instructions that Rosetta cannot emulate and the app crashes due to that.

This doesn't happen in .NET 9, since we always clear the CONTEXT_XSTATE before
exception handling stack unwinding. But in .NET 8, this causes stack overflow
under Rosetta, since the attemt to execute the ymm instruction triggers the
hardware exception handling again and again.
@github-actions github-actions bot locked and limited conversation to collaborators Oct 2, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants