[springmin]

Summary

The CoreCLR W^X allocator keeps code in a double mapping: a read-write view and a
read-execute view of the same memfd-backed pages. On OpenHarmony the sandbox denies
PROT_EXEC for those file-backed mappings, so the executable view cannot be created
and JIT-compiled code cannot run there; anonymous executable memory is allowed.

Default EnableWriteXorExecute to 0 on TARGET_OPENHARMONY, extending the condition
that already selects the RWX allocator for RISC-V, so OpenHarmony builds JIT out of the
box. The knob is otherwise unchanged: DOTNET_EnableWriteXorExecute=1 still requests
W^X.

Changes

• src/coreclr/inc/clrconfigvalues.h: change the #ifdef TARGET_RISCV64 guard around
  EXTERNAL_EnableWriteXorExecute to
  #if defined(TARGET_RISCV64) || defined(TARGET_OPENHARMONY), so the default is 0 on
  both targets. Two comment lines record the sandbox reason; the trailing #endif
  comment follows.

Impact

• OpenHarmony only. TARGET_OPENHARMONY is defined by the platform build support in
  Add OpenHarmony/HarmonyOS build infrastructure #132953; every other target, RISC-V included, takes the same branch as before and
  keeps the default of 1.
• One file, 4 insertions and 2 deletions. No managed API, build, or test changes.
• W^X stays available as an opt-in through DOTNET_EnableWriteXorExecute=1 for sandbox
  configurations that permit file-backed executable mappings.

Validation

• On an OpenHarmony arm64 device, with DOTNET_EnableWriteXorExecute unset, a
  framework-dependent console app (DOTNET_ReadyToRun=0) runs to completion; the
  executable allocator reports no EACCES failures.
• Negative control on the same build: DOTNET_EnableWriteXorExecute=1 fails when the
  allocator makes the double-mapped file executable, which is the failure this default
  avoids.
• Direct probe behind the comment: on this device a memfd mapping cannot be given
  PROT_EXEC (mprotect returns EACCES), while an anonymous mapping can be flipped
  from RW to RX and executed.

Test

1. Build CoreCLR for openharmony-arm64 with the OpenHarmony platform support from
   Add OpenHarmony/HarmonyOS build infrastructure #132953 (this defines TARGET_OPENHARMONY).
2. On the device, run a framework-dependent console app with DOTNET_ReadyToRun=0 and
   no DOTNET_EnableWriteXorExecute set; it should complete normally.
3. As a negative control, run the same app with DOTNET_EnableWriteXorExecute=1; it is
   expected to fail when code memory is made executable.
4. Check that the diff against upstream/main is limited to the
   src/coreclr/inc/clrconfigvalues.h guard.

Note

This PR was authored with AI assistance (agent tooling) under the author's direction.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[jkotas]

/ba-g non-essential leg failed due to flaky network