Allow execution of R2R code in singlefile app on windows.

[VSadov]

The following changes were made:

• Copy executable PE sections in LayoutILOnly, if there are any, into executable memory.
• Apply relocs if R2R code is present.
• Exception stuff (RtlAddFunctionTable / RtlDeleteFunctionTable for non-x86 unwind).

Fixes:#39409

[VSadov]

Timing execution of HelloWorld app

=== baseline (not singlefile, self-contained app):
$ time for i in {1..10}; do ./hello.exe > /dev/null; done

real 0m0.954s
user 0m0.030s
sys 0m0.199s

=== singlefile app before this change:
$ time for i in {1..10}; do ./hello.exe > /dev/null; done

real 0m1.216s
user 0m0.030s
sys 0m0.137s

=== singlefile app after this change:
$ time for i in {1..10}; do ./hello.exe > /dev/null; done

real 0m0.909s
user 0m0.030s
sys 0m0.121s

[ghost]

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

[VSadov]

I think this is ready to be reviewed.

[VSadov]

cc:@agocke

[jkotas]

We should not be leaving any pages mapped as RWX.

[VSadov]

I have seen this used in other cases.

runtime/src/coreclr/src/pal/src/map/virtual.cpp

Line 614 in 6072e4d

MemAccessControl = PAGE_EXECUTE_READWRITE;

, so I assumed we may need to keep fidelity with what PE says - if it is RWX section then it should be mapped to RWX memory.

In reality, I think I have never seen RWX actually happening here. I think R2R code is always RX, perhaps intentionally.
I think for our purposes we could just handle RWX case as RX here.

[jkotas]

The Windows PE loader ignores executable permissions for IL-only images. It will never map executable sections in IL images as executable, even if the PE file asks for it.

This was defense-in-depth security mitigation, implemented long time in .NET Framework days. It is probably not as important now compared to how important it used to be, but it would not hurt to keep it.

[VSadov]

The memory must be executable so that we could execute code. It does not need to be writeable though. Not for R2R stuff.
I have changed this to PAGE_EXECUTE_READ for executable sections regardless of writeability.

[jkotas]

Is this going to enable loading R2R images via e.g. Load(byte[]) ? I am not sure whether it is something we want to enable.

[VSadov]

Is the concern that we would do redundant relocations or that the R2R code might be made to run via reflection?

Assuming that R2R code does the same thing as corresponding IL, I do not see problems with the latter. Perhaps even a good thing.

That is - if that actually works.
I did not think that Load(byte[]) might hit this codepath. I will have to check what really happens.

[VSadov]

I checked Load(byte[]) scenario and it appears to not using this codepath. Load(byte[]) creates RawImageLayout and that does not come here.

[VSadov]

ConvertedImageLayout is used explicitly when loading from a Bundle.
There is also another codepath that could lead to creating ConvertedImageLayout. I am not sure if it is used and in what cases.

It should be possible to remember that the file was loaded form a bundle and perform the above just in those cases to be sure it does not enable more scenarios than needed.

[VSadov]

Added m_isInBundle to ConvertedImageLayout - to make sure this does not get enabled in other cases.

[VSadov]

In theory it is possible that ConvertedImageLayout could be used for other purposes, but even if it happens it seems to be rare. I have made a trial change where creating ConvertedImageLayout not for a purpose of a file in a bundle would assert and throw, and the change passed all CI tests. (#40403)

Anyways, we now should be relocating only when ConvertedImageLayout was created for a file in a bundle. If the other scenarios are reachable, they will still retain previous behavior.

[jkotas]

LGTM

[VSadov]

Thanks!!!