ThunkPool doesn't work with PROCESS_MITIGATION_DYNAMIC_CODE_POLICY

[MichalStrehovsky]

Reported by internal customer. When PROCESS_MITIGATION_DYNAMIC_CODE_POLICY are enabled, the VirtualProtect call we use to mark memory as Execute/Read fails with STATUS_DYNAMIC_CODE_BLOCKED that we then translate into OOM.

I guess we should investigate whether we could do !FEATURE_RX_THUNKS on Windows too.

CsWinRT is going to look into avoiding GetFunctionPointerForDelegate, but this also affects IDynamicInterfaceCastable with shared generic types (that CsWinRT is also trying to work around, but people could still hit in the past).

[filipnavara]

What exactly is the ask? We can just flip the switch on win-x64/win-arm64 today. The implementation is already there, builds and passes the smoke tests. I can probably contribute win-x86 if that's a blocker.

[MichalStrehovsky]

What exactly is the ask? We can just flip the switch on win-x64/win-arm64 today. The implementation is already there, builds and passes the smoke tests. I can probably contribute win-x86 if that's a blocker.

1. I didn't know if it didn't bitrot, never tried disabling it.
2. I don't know why we don't just use !FEATURE_RX_THUNKS by default, it seems better in all ways on the surface, but I assume there was a reason why we didn't just switch to it (the !FEATURE_RX_THUNKS codepaths were added for Xbox during .NET Native times IIRC).

[filipnavara]

It didn't bitrot. I tested it on win-x64 today and on win-arm64 not too long ago. I'd be in favor of enabling it by default.

(We don't have working Linux implementation but it was requested in separate issue for HarmonyOS port. We also don't have the x86 version of the assembly files but that's relatively small thing to fix.)

[filipnavara]

Turns out I was wrong and there's a bitrot after all. Specifically, the sections produced in the executable are not in the correct order. .NET Native used a custom linker script to order them in mrt100_app.dll.

[MichalStrehovsky]

Turns out I was wrong and there's a bitrot after all. Specifically, the sections produced in the executable are not in the correct order. .NET Native used a custom linker script to order them in mrt100_app.dll.

I found the old wisdom in the .NET Native tree including the undocumented link.exe argument. I'll give it a stab.

[MichalStrehovsky]

This doesn't look fixable. !FEATURE_RX_THUNKS makes it work halfway. But since this is in a locked down mode, it's a reasonable assumption that whoever would hit this would be also using control flow guard. And it doesn't work with control flow guard.

• !FEATURE_RX_THUNKS in combination with control flow guard and no PROCESS_MITIGATION_DYNAMIC_CODE_POLICY hits a problem the second time we try to SetProcessValidCallTargets (the first time we do it on memory that was mapped by the OS, the second time it's memory that was remapped by us).
• !FEATURE_RX_THUNKS in combination with control flow guard and enabled PROCESS_MITIGATION_DYNAMIC_CODE_POLICY hits a problem that SetProcessValidCallTargets is completely disallowed under PROCESS_MITIGATION_DYNAMIC_CODE_POLICY

The "completely disallowed" part is not documented but per https://troopers.de/media/filer_public/f6/07/f6076037-85e0-42b7-9a51-507986edafce/the_joy_of_sandbox_mitigations_export.pdf:

What Does it Disable?

• Calling VirtualAlloc with PAGE_EXECUTE_*
• MapViewOfFile with FILE_MAP_EXECUTE option
• Calling VirtualProtect with PAGE_EXECUTE_* etc.
• Reconfiguring the CFG bitmap via SetProcessValidCallTargets

(We don't care about the MapViewOfFile restriction since we don't use FILE_MAP_EXECUTE, but the SetProcessValidCallTargets restriction completely shatters it.)

I think the maximum we can do this would be to fail with a different exception than OOM.