You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#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.
The text was updated successfully, but these errors were encountered:
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?
#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 inB.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.
The text was updated successfully, but these errors were encountered: