Enable CFG support in ProjectN

Today our ProjectN images are not CFG-enabled, but CFG will kick in for applications that have CFG enabled, in particular, WWAHost (for JavaScript apps). Today with those apps and dynamic interop enabled we would trigger a CFG check as those thunks are never registered under CFG.

There are a couple of ways to achieve this. 1) You could take advantage of the CFG table which OS loader understands and would remap in MapViewOfFile. In order to make those thunks show up in CFG, you need to give them symbolic names. According to my testing, it only seem to work if we map the full mrt100_app.dll, which isn't ideal. 2) Use SetProcessValidCallTargets and supply the thunks. I went with SetProcessValidCallTargets, which works, but has its own set of challenges (if we discover that OS matrix we need to support with CFG becomes unsustainable with this approach we can revisit):

1. Our ARM test environment is on 8.1, while SetProcessValidCallTargets is Win10+.

Normally you would fix this by either 1) LoadLibrary/GetProcAddress or 2) delay loading. Unfortunately none of these work today because LoadLibrary is not part of WACK (and has a non-trivial cost to support) and 2) SetProcessValidCallTargets is on kernel32 and not delay loadable.

Fortunately there is a API set available load api-ms-win-core-memory-l1-1-3.dll which will has this API. It is effectively forwarded to kernelbase.dll but for the purpose of delay loading it works perfectly. When the API is not found, we would redirect the API to a predefined failure stub that simply returns true.

It is worth noting that if we opt to use LoadLibrary/GetProcAddress (which you can't do under UWP), calling SetProcessValidCallTarget would trigger CFG check as it is declared __declspec(guard(nocf)) for security reasons. Fortunately delay loading works fine.

2. Calling SetProcessValidCallTargets would fail on non-CFG-enabled processes. This can be fixed by calling GetProcessMitigationPolicy to determine whether the process is CFG-enabled.

3. SetProcessValidCallTargets require our thunks to be 0x10 aligned. x64/ARM is already 0x10 aligned but x86 is only aligned on 0x4. This means we'll need to waste 0xc for each thunk on x86. This a bit unfortunate but I doubt anyone would care. If this ends up wasting too much space we can revisit and optimize as needed.

4. SetProcessValidCallTargets is not allowed in WACK today. Fortunately it is already on pre-approved WACK list for RS2. It does mean that you won't be able to submit apps with mrt100_app.dll today but that's probably fine - our plan for the new toolchain is RS3+.

5. Our toolsets in razzle enlistment only has 8.1 the latest. For now I've work arounded by manually declaring the imports and copy the latest mincore.lib to rh/public/minwin folder. This has a unfortunate side effect that it also 'upgrades' RaiseFailFastException to a new API set that is not available down-level 8.1. I've made RaiseFailFastException also delay loading so that we wouldn't immediately fail to load under ARM + Win 8.1. I doubt any one cares about how N failfast under 8.1.

6. Similarly, ToF also has a copy of Win8 toolset in its own ExternalAPI (not the razzle one) and it doesn't support creating a CFG-aware binary. One possiblity is to use JavaScript app like in the bug, but you also need a reliable way to construct thunks and send it over to javaScript as v-table so that JavaScript can call it. This is basically dyanmic interop feature so the best way to cover this today without CFG-aware toolset is in dyanmic interop testing with full dyanmic interop mode on (everything dynamic). Once we have a CFG-aware toolset (I suspect this would only happen when we move out of ToF), we can have the main C++ app call reverse p/invoke thunks.

I've introduced a new API PalMarkThunksAsValidCallTargets to do the heavylifting - to allocate the correct data structure ro register the thunks and call SetProcessValidCallTargets. Rest of the stuff are less interesting.

After this change, I've verified the Yahoo app with dynamic interop turned on can proceed further (but still eventually timed out). I've also done a few more testing:
* ARM 8.1 private interop run,
* x86 private interop run,
* thunkpool tests
* x86chk precheckin
* verified ARM phone does have SetProcessValidCallTargets API.
* Build and ran all CoreRT tests

[tfs-changeset: 1655595]

2 files changed, 4 insertions, 3 deletions

diff --git a/src/Runtime.Base/src/System/Runtime/InternalCalls.cs b/src/Runtime.Base/src/System/Runtime/InternalCalls.cs
index 943c3c14f..3fb169472 100644
--- a/src/Runtime.Base/src/System/Runtime/InternalCalls.cs
+++ b/src/Runtime.Base/src/System/Runtime/InternalCalls.cs
@@ -392,10 +392,10 @@ namespace System.Runtime
         [ManuallyManaged(GcPollPolicy.Never)]
         internal extern static IntPtr RhpGetThunkStubsBlockAddress(IntPtr thunkDataAddress);
 
-        [RuntimeImport(Redhawk.BaseName, "RhpGetNextThunkStubsBlockAddress")]
+        [RuntimeImport(Redhawk.BaseName, "RhpGetThunkBlockSize")]
         [MethodImpl(MethodImplOptions.InternalCall)]
         [ManuallyManaged(GcPollPolicy.Never)]
-        internal extern static IntPtr RhpGetNextThunkStubsBlockAddress(IntPtr currentThunkStubsBlockAddress);
+        internal extern static int RhpGetThunkBlockSize();
 
         //------------------------------------------------------------------------------------------------------------
         // PInvoke-based internal calls
diff --git a/src/Runtime.Base/src/System/Runtime/ThunkPool.cs b/src/Runtime.Base/src/System/Runtime/ThunkPool.cs
index 91371573f..67869d4ec 100644
--- a/src/Runtime.Base/src/System/Runtime/ThunkPool.cs
+++ b/src/Runtime.Base/src/System/Runtime/ThunkPool.cs
@@ -389,10 +389,11 @@ namespace System.Runtime
                 // Each mapping consists of multiple blocks of thunk stubs/data pairs. Keep track of those
                 // so that we do not create a new mapping until all blocks in the sections we just mapped are consumed
                 IntPtr currentThunksBlock = nextThunksBlock;
+                int thunkBlockSize = InternalCalls.RhpGetThunkBlockSize();
                 for (int i = 0; i < Constants.NumThunkBlocksPerMapping; i++)
                 {
                     s_currentlyMappedThunkBlocks[i] = currentThunksBlock;
-                    currentThunksBlock = InternalCalls.RhpGetNextThunkStubsBlockAddress(currentThunksBlock);
+                    currentThunksBlock += thunkBlockSize;
                 }
                 s_currentlyMappedThunkBlocksIndex = 1;
             }