When running the .Net Core version of the F# Interactive Service we get a security exception on any invocation of a PInvoke call that was generated in the script itself.
- Start .Net Core version of fsi.exe
dotnet 'C:\Program Files\dotnet\sdk\3.0.100-preview-009812\FSharp\fsi.exe'
- Enter the following script:
open System.Runtime.InteropServices
[<DllImport("kernel32")>]
extern int GetLastError()
GetLastError()
- You'll see the following exception:
System.Security.SecurityException: ECall methods must be packaged into a system module.
at <StartupCode$FSI_0012>.$FSI_0012.main@()
Stopped due to error
On .Net Framework fsi this will execute and return the last error this is just the simplest test case I could think of.
I investigated and this is due to a check in ecall.cpp:346 inside the coreclr project.
if (!pMD->GetModule()->IsSystem())
COMPlusThrow(kSecurityException, BFA_ECALLS_MUST_BE_IN_SYS_MOD);
They perform a check on the incoming module to see if it is a system module (My guess is this means it's loaded from disk?) In any case if it is not then they throw this error. This means any scripts that were using PInvoke to call win32 services or other C api's CAN NOT work on the CoreCLR fsi version.
I've confirmed this is the case with .Net Core 2.0, 2.1, 2.2 and 3.0 preview at the exact same line number.
It there something that can be done to let the CoreCLR system know that the dynamically generated FSI assemblies are ok as far as this check is concerned?
Thanks,
-Patrick Simpson
DotNetFSISecurityFailureTest.zip
When running the .Net Core version of the F# Interactive Service we get a security exception on any invocation of a PInvoke call that was generated in the script itself.
On .Net Framework fsi this will execute and return the last error this is just the simplest test case I could think of.
I investigated and this is due to a check in ecall.cpp:346 inside the coreclr project.
They perform a check on the incoming module to see if it is a system module (My guess is this means it's loaded from disk?) In any case if it is not then they throw this error. This means any scripts that were using PInvoke to call win32 services or other C api's CAN NOT work on the CoreCLR fsi version.
I've confirmed this is the case with .Net Core 2.0, 2.1, 2.2 and 3.0 preview at the exact same line number.
It there something that can be done to let the CoreCLR system know that the dynamically generated FSI assemblies are ok as far as this check is concerned?
Thanks,
-Patrick Simpson
DotNetFSISecurityFailureTest.zip