dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.14k stars 4.71k forks source link

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

Open jnyrup opened 4 months ago

jnyrup commented 4 months ago

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 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-policy-service[bot] commented 4 months ago

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

jnyrup commented 3 months ago

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 commented 1 month ago

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

mangod9 commented 1 month ago

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