WASI payload working in Wasmtime, not working in Lunatic

[delneg]

Hello, I've tried to run a demo WASI application build using F# & .NET 7.0 using https://github.com/SteveSandersonMS/dotnet-wasi-sdk on Lunatic and I'm getting the following error:

$ WASMTIME_BACKTRACE_DETAILS=1 RUST_BACKTRACE=1 lunatic bin/Release/net7.0/FullstackWasmFSharpAppBackend.wasm -- --tcplisten localhost:8080 --env ASPNETCORE_URLS=http://localhost:8080

Unhandled Exception:
System.EntryPointNotFoundException: SystemNative_ReadLink
   at Interop.Sys.ReadLink(Byte& path, Byte[] buffer, Int32 bufferSize)
   at Interop.Sys.ReadLink(ReadOnlySpan`1 path)
   .....
      at Program.main(String[] args)
   [2022-06-10T21:25:40Z WARN  lunatic_process] Process 5becaa45-c926-4a8e-918b-523ef9c72714 failed, notifying: 0 links 
                            (Set ENV variable `RUST_LOG=lunatic=debug` to show stacktrace)
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Exited with i32 exit status 1
wasm backtrace:
    0: 0x35b5 - SystemNative_MAdvise
                    at /home/runner/work/dotnet-wasi-sdk/dotnet-wasi-sdk/modules/runtime/src/native/libs/System.Native/pal_io.c:978:37
', src/mode/execution.rs:104:16
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt

The application in question is here: https://github.com/delneg/FullstackWasmFSharpApp

Looking at src/native/libs/System.Native/pal_io.c:978:37 from dotnet-wasi-sdk (https://github.com/dotnet/runtime/blob/cdce8167ad107c385189b3b85fd4fc22379c4f3f/src/native/libs/System.Native/pal_io.c#L978) I don't see anything related to the above error SystemNative_ReadLink which is actually located here:
https://github.com/dotnet/runtime/blob/82a2562fc9ee0986ee20ee309ad0bc259c561683/src/native/libs/System.Native/pal_io.h#L665

From what I understand, somehow function pointers are not working as they should in this case.
If this issue is not related to lunatic, feel free to close.

[bkolobara]

This issue is related to the new WASI sock_accept proposal that .NET uses for this demo. Lunatic just doesn't support it yet.

What is actually happening here is that lunatic pre-opens the current working dir for the guest. This ends up having the file descriptor 3 (0,1,2 being reserved for stdio). Now, .Net is trying to use file descriptor 3 as a listening socket and fails, because it's actually a dir. The same can be reproduced with wasmtime:

wasmtime bin/Debug/net7.0/FullstackWasmFSharpAppBackend.wasm --dir=.

Unhandled Exception:
System.EntryPointNotFoundException: SystemNative_ReadLink
   at Interop.Sys.ReadLink(Byte& path, Byte[] buffer, Int32 bufferSize)
   at Interop.Sys.ReadLink(ReadOnlySpan`1 path)
   ...

It's not really clear to me how sock_accept is supposed to work. Why do sockets get a lower fd than preopend dirs? And it seems like there is no way for the guest to get any information about the socket. E.g.

wasmtime bin/Debug/net7.0/FullstackWasmFSharpAppBackend.wasm --tcplisten localhost:6000
info: Microsoft.Hosting.Lifetime
      Now listening on: http://localhost:5000

Notice that the output is always http://localhost:5000, no matter what the actual listening port is. There is no way for the guest to know, it just uses the FD 3, no matter what is bound to it.

We could do the same as wasmtime, let the user pre-open file descriptors using a "convention" where we assign lower numbers to FD (starting from 3) if they are listening sockets and have the guest "hardcode" this values? It just seems like a random decision to me to do it that way and conflicts a bit with our current Tcp primitives.