Windows executables: only load imported DLLs from System32

[AustinWise]

By using the /DEPENDENTLOADFLAG link.exe flag, we can tell the Windows loader to only look for referenced DLLs in the System32 directory. This prevents DLL injection, like #87495 recently fixed.

This covers the main CoreCLR product DLLs and EXEs:

• coreclr.dll
• clrjit.dll
• createdump.exe
• apphost.exe
• dotnet.exe
• singlefilehost.exe
• comhost.dll
• hostfxr.dll
• hostpolicy.dll
• ijwhost.dll
• nethost.dll
• clrcompression.DLL

Questions

Is there a better way to apply this flag in the CMake files? Initially I tried adding this to all executables by defining the flag in eng/native/, but some tests broke because they rely on loading DLLs from places other than System32.

EDIT: I moved the setting to eng/native/configurecompiler.cmake and disabled the linker flag for IJW tests.

When I added this flag, I got this error message from LINK.exe:

LINK : fatal error LNK1268: inconsistent option 'DEPENDENTLOADFLAG:0x800' specified with /USEPROFILE but not with /GENPROFILE

How can this be worked around? Currently I have commented out applying PGO to make the build pass.

EDIT: We can leave the application of PGO commented out until updated PGO files are available.

[ghost]

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

Issue Details

---

By using the /DEPENDENTLOADFLAG link.exe flag, we can tell the Windows loader to only look for referenced DLLs in the System32 directory. This prevents DLL injection, like #87495 recently fixed.

This covers the main CoreCLR product DLLs and EXEs:

• coreclr.dll
• clrjit.dll
• createdump.exe
• apphost.exe
• dotnet.exe
• singlefilehost.exe
• comhost.dll
• hostfxr.dll
• hostpolicy.dll
• ijwhost.dll
• nethost.dll

Questions

Is there a better way to apply this flag in the CMake files? Initially I tried adding this to all executables by defining the flag in eng/native/, but some tests broke because they rely on loading DLLs from places other than System32.

When I added this flag, I got this error message from LINK.exe:

LINK : fatal error LNK1268: inconsistent option 'DEPENDENTLOADFLAG:0x800' specified with /USEPROFILE but not with /GENPROFILE

How can this be worked around? Currently I have commented out applying PGO to make the build pass.

Author:	AustinWise
Assignees:	-
Labels:	area-Host
Milestone:	-

[vitek-karas]

@elinor-fung as our inhouse DLL loading expert :-)

[elinor-fung]

Is there a better way to apply this flag in the CMake files? Initially I tried adding this to all executables by defining the flag in eng/native/, but some tests broke because they rely on loading DLLs from places other than System32.

For the binaries under src/native/corehost, you could put the option under exe.cmake and lib.cmake, which will be used by product executables/libraries but not tests.

Do you recall which tests these were? If it is an isolated set, you could have them explicitly remove the option. We do something like that for IJW tests:

runtime/eng/native/ijw/IJW.cmake

Line 3 in 2470610

function(remove_ijw_incompatible_optionsoptionsupdatedOptions)

When I added this flag, I got this error message from LINK.exe:

LINK : fatal error LNK1268: inconsistent option 'DEPENDENTLOADFLAG:0x800' specified with /USEPROFILE but not with /GENPROFILE

How can this be worked around? Currently I have commented out applying PGO to make the build pass.

I believe this is because the data files used for PGO optimization need to be collected/applied withbinaries that use identical options. One option would be to do this in two stages:

• Temporarily add the flag only when instrumenting
• Once we have new profile data with that flags, switch to adding that flag both when instrumenting and optimizing

@jkoritzinsky / @agocke do you know if there's a better way to do this?

[jkoritzinsky]

Generally when we change options in an instrumenting-incompatible way, we just disable PGO optimization as part of the change until new data has been generated and flows back into the runtime. Your idea actually sounds nicer than our usual approach.

I think we should at least wait until after the snap (so wait until tomorrow) before taking a PGO-incompatible change just to simplify code flow.

[elinor-fung]

I think we should at least wait until after the snap (so wait until tomorrow) before taking a PGO-incompatible change just to simplify code flow.

Agreed.

[AustinWise]

Thanks for the pointer to the IJW file. I will try to do something like that for tests that break when this linker flag is applied globally. I'll un-draft this PR once it get everything building again.

[AustinWise]

It looks like it was just the IJW tests in src\tests and src\installer\tests\ that were failing. By disabling the linker flags in IJW.cmake, now all tests are passing.

[elinor-fung]

cc @GrabYourPitchforks@blowdart

[elinor-fung]

This looks good to me.

I just want to make sure we are in a good position to get updated PGO data and re-enable PGO once this goes in.

@DrewScoggins - we haven't gotten new PGO data in over a month. It looks like the internal dotnet-optimization builds have been failing or timing out. Do you know if this is a known issue or something that still needs to be investigated?

[DrewScoggins]

It is currently being investigated. The current issue I am working through is related a dependency of the repo using an insecure version of a dependency. I will keep things updated as we work through the issues.

[DrewScoggins]

The scenario issue is fixed, but now we are seeing an internal runtime error when doing collection. I have created the issue below to track it.

#90962

[elinor-fung]

Thanks @DrewScoggins. I see dotnet-optimization is back up and we are taking updates (#91171) again - yay!

[elinor-fung]

Thanks, @AustinWise! Merging this.