Open jnyrup opened 5 months ago
Tagging subscribers to this area: @mangod9 See info in area-owners.md if you want to be subscribed.
@mangod9 Have you a chance to look at my question above regarding the milestone?
yeah changed it to 8, we are still evaluating whether to port to 8.
https://github.com/dotnet/runtime/pull/101490#issuecomment-2083213585 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 itsruntimeconfig.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.