Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Getting HighEntropyVACheck on dotnet core generated assembly #101

Closed
TravisEz13 opened this issue Nov 8, 2017 · 4 comments
Closed

Getting HighEntropyVACheck on dotnet core generated assembly #101

TravisEz13 opened this issue Nov 8, 2017 · 4 comments

Comments

@TravisEz13
Copy link
Member

We are getting HighEntropyVACheck on a dotnet core generated assembly defined by this csproj

https://github.com/PowerShell/PowerShell/blob/master/src/powershell-win-core/powershell-win-core.csproj
I don't think this is valid, for a dotnet assembly.

Build instructions are here: https://github.com/PowerShell/PowerShell/blob/master/docs/building/windows-core.md

@Evmaus-MS
Copy link

Evmaus-MS commented Dec 6, 2017

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
Copy link

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

@TravisEz13
Copy link
Member Author

TravisEz13 commented Dec 6, 2017

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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants