Getting HighEntropyVACheck on dotnet core generated assembly about binskim

[Evmaus-MS]

Hey Travis:

Sorry about the slow reply here--I'll need to validate something about HighEntropyVA with someone before I can say it definitely doesn't apply for an ILOnly assembly. (This is edited--I originally said this was not the case, and was filtered out, but I was recalling a different check.)

However, as I understand it, the .net core Self Contained Deployments use something similar to NGEN, which means you're actually producing a native executable. This is definitely the case on Linux, where you get ELF executables.

As I'd expect, too, the CLR headers aren't present on pwsh.exe--if you run dumpbin /clrheader pwsh.exe, you only get:

Dump of file pwsh.exe

File Type: EXECUTABLE IMAGE

Summary

    1000 .data
    1000 .pdata
    9000 .rdata
    1000 .reloc
   20000 .rsrc
    9000 .text
    1000 .tls

Whereas on a .NET assembly, you'd get CLR header options (incl. ILOnly, as below), as you see with dumpbin /clrheader BinSkim.exe (output is similar for a .NET core framework dependent compilation, as well):

Dump of file binskim.exe

FileType: EXECUTABLE IMAGE

clr Header:

          48 cb
        2.05 runtime version
        3304 [    5264] RVA [size] of MetaData Directory
           1 flags
               IL Only
     6000037 entry point token
        8568 [     A10] RVA [size] of Resources Directory
           0 [       0] RVA [size] of StrongNameSignature Directory
           0 [       0] RVA [size] of CodeManagerTable Directory
           0 [       0] RVA [size] of VTableFixups Directory
           0 [       0] RVA [size] of ExportAddressTableJumps Directory
           0 [       0] RVA [size] of ManagedNativeHeader Directory

Summary

    2000 .rsrc
    8000 .text

You may want to reach out to the .NET Core folks to check about the details of self contained deployments vs. framework dependent ones.

Thanks,
Everett Maus

[Evmaus-MS]

After going back over some things--it also does look like /highentropyva does apply to ILOnly assemblies, at least on Windows.

[TravisEz13]

pwsh.dll was actually the flagged binary ( an odd quirk of how EXE's works in netcore, this is where OUR code live, pwsh.exe is just dotnet.exe renamed.) I was given a workaround.
We added the following line to our common props:

<HighEntropyVA>true</HighEntropyVA>
https://github.com/PowerShell/PowerShell/blob/5d8999e8b5aa472139f18e9b437dbcd17d494565/PowerShell.Common.props#L107

This issue was filed:
dotnet/sdk#1735

[TravisEz13]

I don't think this is a binskim issue. Closing.