You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Don Syme asked me to move this bug from fsharp/fsharp issue 886 to here. I describe a failure mode where F# interactive running under .Net Core won't generate correct PInvoke calls in your scripts. It was determined by @jkotashere and @KevinRansomhere that the issue was related to originally missing functionality in .Net Core's Reflection.Emit.TypeBuilder that is now present in .Net Core 3.0.
Considering that we now have F# 4.6 FSI as a preview dotnet command dotnet fsi inside the .Net Core 3.0 preview 3 this needs to get fixed otherwise any existing scripts using PInvoke will not work reporting a rather esoteric error message. This is still an issue under 3.0.100-preview3-010431 running Microsoft (R) F# Interactive version 10.4.0 for F# 4.6
Here is the original issue:
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.
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?
Don Syme asked me to move this bug from fsharp/fsharp issue 886 to here. I describe a failure mode where F# interactive running under .Net Core won't generate correct PInvoke calls in your scripts. It was determined by @jkotas here and @KevinRansom here that the issue was related to originally missing functionality in .Net Core's Reflection.Emit.TypeBuilder that is now present in .Net Core 3.0.
Considering that we now have F# 4.6 FSI as a preview dotnet command dotnet fsi inside the .Net Core 3.0 preview 3 this needs to get fixed otherwise any existing scripts using PInvoke will not work reporting a rather esoteric error message. This is still an issue under 3.0.100-preview3-010431 running Microsoft (R) F# Interactive version 10.4.0 for F# 4.6
Here is the original issue:
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
The text was updated successfully, but these errors were encountered: