Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible backport of "Read EnableWriteXorExecute from runtimeConfig" to .NET 8 #103340

Open
jnyrup opened this issue Jun 12, 2024 · 4 comments
Open
Milestone

Comments

@jnyrup
Copy link
Contributor

jnyrup commented Jun 12, 2024

#101490 (comment) asked for a scenario to justify backporting the PR to .NET 8, but the PR has since been auto-closed, hence this new issue and an attempt to provide a justification.

Searching previous issues and most recently #102226 and #103063 are examples where the workaround to a crash or performance regression is to disable W^X by setting the environment variable DOTNET_EnableWriteXorExecute=0.

In our case we need to disable EnableWriteXorExecute for a particular application due to #75455.
As we run this application in Visual Studio, AWS Elastic Beanstalk (EB) and AWS Elastic Container Services (ECS) we would need to set that environment variable three different places.
This is doable but is an annoyance having to do it in multiple places "far away" from the part of the code needing to have W^X disabled.

As W^X is a security feature one should preferably only disable it where necessary.
Imagine we have the project structure A -> { B, C } (A is compiled with either project B or C) and only B requires disabling W^X.
Disabling W^X globally for A also disables it when compiled together with project C.
Being able to disable W^X in project B either in its runtimeconfig.template.json or in B.csproj and in combination with <GenerateRuntimeConfigurationFiles> should ensure that W^X is only disable when compiling project A together with project B.
This could be further expanded to e.g. only disable W^X when compiling for a certain OS or CPU arch.

Let me know if this is the kind of scenario/justification that was sought to help determining if backporting to .NET 8 is feasible.

@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Jun 12, 2024
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Jun 12, 2024
@vcsjones vcsjones added area-VM-coreclr and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Jun 12, 2024
Copy link
Contributor

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

@mangod9 mangod9 removed the untriaged New issue has not been triaged by the area owner label Jul 3, 2024
@mangod9 mangod9 added this to the 9.0.0 milestone Jul 3, 2024
@jnyrup
Copy link
Contributor Author

jnyrup commented Jul 16, 2024

I might be misunderstanding this project's use of milestones, but I'm a bit confused about why this is added to the 9.0.0 milestone.
Since #101490 is already in main, shouldn't the milestone for a backport be e.g. 8.0.x?

@jnyrup
Copy link
Contributor Author

jnyrup commented Aug 28, 2024

@mangod9 Have you a chance to look at my question above regarding the milestone?

@mangod9
Copy link
Member

mangod9 commented Sep 4, 2024

yeah changed it to 8, we are still evaluating whether to port to 8.

@mangod9 mangod9 modified the milestones: 9.0.0, 8.0.x Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants