Winsock transport provider for WSL via eBPF for Windows

[ohault]

WSL team is currently using 9P to bridge the Linux and Windows sides, but I wonder if the eBPF for Windows architecture could not also support a better way for Windows Apps and Services to leverage Linux networking stack.

I can especially think about leveraging Multipath TCP that will come along with Linux 5.15 kernel, which is almost ready for a upcoming WSL update.

I would see this as implementing a Winsock transport provider on top of eBPF for Windows integrated with eBPF in WSL/Linux kernel

Does it make sense ?

[poornagmsft]

@ohault Thank you for the suggestion. We would love to listen and learn more about this from you. Could you elaborate more on the idea here? The extension architecture allows developers to define arbitrary ebpf program contracts using public APIs. While TDIs are deprecated, a Windows filtering platform callout could be turned into an eBPF hook as we have demonstrated for bind() monitoring. Are you suggesting a way to redirect host's connections from arbitrary windows apps into the linux kernel so that then they can use the multipath functionality?

[ohault]

The general idea is quite simple. As a lot of network stack innovations are developed firstly for Linux like Mutlipath TCP (mptcp), WSL could leverage these innovations.

Using the current WSL2 architecture, we can imagine to interface Windows network APIs (like Winsock API) to use the 9p (client side under Windows, server side under Linux) to snap into the Linux kernel equivalent implementation. By the way, Windows apps and and NT services, could leverage the Linux network protocol stack (hence mptcp implementation). It is somehow similar to the WINE implementation Winsock API but with a clear boundary between Windows and Linux sides.

With eBPF for Windows progresses, I guess there will be new bridging/integration opportunities between both stacks.

Is there already research in this direction ?

[Alan-Jowett]

@ohault this is an interesting idea. It sounds like what you are looking for is a layer 7 redirect from one Hyper-V partition to another.

Unfortunately, 9p on Windows doesn't expose the endpoints as sockets, so I am not if socket redirection would work. Hyper-V sockets appear to be the only socket style supported for cross-partition.

Under this model, it would work something like this:

1. Client calls bind or connect -> BPF program redirects this to a localhost socket to Windows daemon and also captures the original bind/connection parameters.
2. Windows daemons calls Linux daemon to do the bind or connect.
3. Linux daemon does the bind or connect.
4. Once the connection is established, Windows and Linux daemons open a Hyper-V socket and use a SOCKMAP to redirect traffic between Hyper-V socket and the underlying WSL2 network stack.

Traffic flow would then be:
App -> BPF -> Hyper-V socket (Windows) -> Hyper-V socket (Linux) -> BPF -> Linux socket.

Note: For this to work, we would need something similar to SOCKMAP for eBPF-for-Windows.